smarthomeng / smarthome Goto Github PK

Hi,

as discussed in the KNXUF the current stat.py is causing an exception due to the fact that this routine is not supported by pyhton < 3.3. From my PoV the basis for SH.PY should be kept identical to the former PI-Image, means 3.2, and so I would suggest to handle this in an individual logic or, if possible, check the version of python as a prereq.

Cheers,
Oliver

• It would be great to present a button for every cache item to delete it.
• It would be nice to have a button for "delete all orphans"
• It would be great to display all cache items with their value and not only the orphaned ones

Um den last outgoing caller richtig zu bekomme, habe ich bei last_caller und last_call_date das cache = yes auskommentiert. Dann liefert das plugin den richtigen Namen für den last caller outgoing.

Wenn ich danach den cache wieder einschalte, bekomme ich wieder den falschen Namen.
Wenn ich den cache wieder ausschalte, bekomme ich wieder den richtigen Namen.

Ich hatte beim ersten mal als ich die cache Zeilen auskommentiert hatte folgende Exception (reproduzierbar). Nach dem wieder einschalten und nochmaligem ausschalten des Caches konnte ich die Exception nicht mehr produzieren.

2016-04-24 17:01:51 ERROR    Main         Item wohnung.fritzbox.monitor_wt.outgoing.last_call_date: problem creating: 'avm_data_type'

Traceback (most recent call last):
  File "/usr/local/smarthomeNG/lib/item.py", line 219, in __init__
    child = Item(smarthome, self, child_path, value)
  File "/usr/local/smarthomeNG/lib/item.py", line 275, in __init__
    update = plugin.parse_item(self)
  File "/usr/local/smarthomeNG/plugins/avm/__init__.py", line 572, in parse_item
    if item.conf['avm_data_type'] in ['is_call_incoming','is_call_outgoing',
KeyError: 'avm_data_type'

Hi there!

When I start smarthomeNG in debug mode I get the following problem (using the wetter.com plugin):

2016-07-30 18:50:41 DEBUG item env_loc Item env.location.sunset = 2016-07-30 20:57:32.536098+02:00 via Logic None None -- item.py:update:374
--- Logging error ---
Traceback (most recent call last):
File "/usr/local/lib/python3.4/logging/__init.py", line 980, in emit
stream.write(msg)
UnicodeEncodeError: 'ascii' codec can't encode character '\xf6' in position 95: ordinal not in range(128)
Call stack:
File "/usr/local/lib/python3.4/threading.py", line 879, in _bootstrap
self._bootstrap_inner()
File "/usr/local/lib/python3.4/threading.py", line 911, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.4/threading.py", line 859, in run
self._target(_self._args, *_self._kwargs)
File "/usr/smarthome/lib/scheduler.py", line 344, in _worker
self._task(name, obj, by, source, dest, value)
File "/usr/smarthome/lib/scheduler.py", line 354, in _task
exec(obj.bytecode)
File "/usr/smarthome/logics/wettercom.py", line 26, in
frame.text(forecast[date][2])
File "/usr/smarthome/lib/item.py", line 287, in call
self.__update(value, caller, source, dest)
File "/usr/smarthome/lib/item.py", line 374, in __update
self._change_logger("Item {} = {} via {} {} {}".format(self._path, value, caller, source, dest))
Message: 'Item wetter.vorhersage.heute.frueh.text = leicht bew\xf6lkt via Logic None None'
Arguments: ()

As it is a "logging error" I guess it's not part of the plugin.. How can I avoid the error? Thanks!!!

Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/cherrypy/_cprequest.py", line 670, in respond
response.body = self.handler()
File "/usr/local/lib/python3.4/dist-packages/cherrypy/lib/encoding.py", line 220, in call
self.body = self.oldhandler(_args, *_kwargs)
File "/usr/local/lib/python3.4/dist-packages/cherrypy/_cpdispatch.py", line 60, in call
return self.callable(_self.args, *_self.kwargs)
File "/usr/local/smarthomeNG_master/plugins/backend/init.py", line 276, in index
self.find_visu_plugin()
File "/usr/local/smarthomeNG_master/plugins/backend/init.py", line 269, in find_visu_plugin
self.logger.warning("Backend: visu plugin v{0} is too old to support BackendServer, please update".format(vers))
NameError: name 'vers' is not defined

Hi René,

ich habe 7 Telefonnummern auf der Fritz!Box. Da wäre es wichtig, wenn ich bei eingehenden Anrufen ermitteln könnte, für welche meiner Nummern der Anruf ist.

Analog (aber nicht ganz so wichtig) für ausgehende Anrufe: Hier wäre es schön, wenn ich ermitteln könnte, unter welcher eigenen Nummer der ausgehende Anruf geführt wird.

Viele Grüße
Martin

Hi,

it seems that due to this line the logfile is logging every 5 mins. the EPHEM-version.

Suggest to change from " logger.info('Ephem Version: {0}'.format(ephem.version)) " to " logger.debug('Ephem Version: {0}'.format(ephem.version)) ". In general the logging of the EPHEM version to an env.-item is brilliant and should be kept.

Cheers,
Oliver

Hi,

eine Sache bei der Verarbeitung von Onewire-Sensordaten ist mir aufegfallen, die ich bisher durch manuelle Anpassungen umgangen habe. Jetzt wird es Zeit das ins Repo zu holen.

Bei default-Einstellungen werden bei mir reproduzierbar falsche Werte (vor allem bei Feuchtigkeutssensoren) in das entsprechende Item geschrieben. Als Beispiel:

30% Luftfeuchte im sh-Item, 38% per Abfrage auf der owserver http-Oberfläche. Nach stundenlangen Ausprobieren habe ich den starken Verdacht, das es ein Timing-Promblem beim Pollen das Onewire-Bus ist. Setze ich im Onewire-Plugin-Code ein Sleep von 1sek zwischen der Verarbeitung der einzelnen Werte des Busses, tritt dieser Fehler nicht auf.

Am Onewire-Bus hängen 8-10 Sensoren, der Fehler ist bei mir reproduzierbar.

Gruss,

Stefan

Hi,
nachdem ich jetzt die Widget Unterstützung incl. js und css fertiggestellt habe, habe ich mir überlegt auch Widgets ausliefern zu können, zu denen es keine Plugins gibt.

Es gibt eine Reihe von Widgets, die allgemeiner Natur sind und keinen Plugin Bezug haben. Um auch diese ausliefern zu können, sind mir zwei Ideen gekommen:

• Diese Widgets werden in einem Sonderverzeichnis (z.B. plugins/_sv_widgets) bereitgestellt
• Es wird möglich Plugins ohne Code einzurichten (z.B. plugins/widgets_xyz) und die Widgets analog zu Widgets bei normalen Plugins handzuhaben.

Zur zweiten Variante habe ich Tests gemacht. Ich benötige nur den class_path Eintrag in der plugins.conf.
Beispiel:

[widgets]
class_path = plugins.widgets_xyz

Allerdings ist das smarthome Pluginhandling noch nicht sehr robust und schmeißt mir Exceptions entgegen wenn ich class_path definiere, aber keinen class_name. Im Moment funktioniert das nur, wenn ich den Classname definiere und eine minimale init.py erstelle.

Die erste Variante kann ich rein im visu Plugin implementieren. Ich finde allerdings die zweite Variante interesanter, da man dann mehrere Gruppen von Widgets definieren kann und der Anwender kann wählen, welche er aktivieren möchte. Dazu wäre jedoch sinnvollerweise eine Anpassung an lib/plugin.py notwendig, damit man nicht class_name definieren und eine dummy init.py anlegen muss.

Welches Vorgehen bevorzugt ihr?

I wonder if someone was thinking about implementing a reload plugins action?
Currently the CLI module allows reloading logics. Wouldn't it be interesting having the same for plugins?

This feature would make it easier to update plugins and keep smarthomeNG core running.

#31

Vorgehen überlegen für die Sicherstellung der Kompatibilität zu Python 3.2 und 3.4

• Zeitraum für unterstützte Python Versionen definieren.
• automatisierte Tests

Due to the discussion about the release planning (#36) I was wondering wheter it might be a good idea to deliver a usage statistics script with shNG.

Something like

• Create a random "ID" and store it to a file
• Poll a script (on GH maybe?) and pass along shNG's version number
• Run the script on each startup

Implementation could be a plugin which gets defaultet to ON at new installations, with a comment in the plugin.conf for the user to deactivate/opt out.

That way decisions may be easier to make, like in the python version discussion.

Opinions?

#31

Release Management im Wiki

Hi René,

ich habe eine meiner 7390 upgedated (die ohne Telefonie Nutzung). Diese Box hat jetzt die Firmware v6.51.

Seitdem habe ich im 5 Minuten Takt folgende Exception im smarthome.log:

2016-05-01 11:49:16 ERROR    plugins.avm_fritz_wz Method plugins.avm_fritz_wz exception: 'NoneType' object has no attribute 'data'
Traceback (most recent call last):
  File "/usr/local/smarthomeNG/lib/scheduler.py", line 358, in _task
    obj()
  File "/usr/local/smarthomeNG/plugins/avm/__init__.py", line 540, in _update_loop
    self._update_wan_ip_connection(item)
  File "/usr/local/smarthomeNG/plugins/avm/__init__.py", line 1556, in _update_wan_ip_connection
    item(element_xml[0].firstChild.data)
AttributeError: 'NoneType' object has no attribute 'data'

Diese Fritz!Box hat keine eigene WAN Verbindung. Der WAN Traffic wird über die andere Box geführt.

Das AVM Plugin ist das Aktuelle (Version 0.961)

Siehe:
https://knx-user-forum.de/forum/supportforen/smarthome-py/944688-problem-beim-auslesen-eines-einzelnen-1wire-sensors

Spricht etwas dagegen die Werte von 1-Wire Sensoren auf mehrere Items zu konfigurieren?
Würde ich sonst als eine Erweiterung des onewire Plugins sehen.
Ob das Sinn macht zwei mal die gleichen Werte zu haben ist ein anderes Thema. Wenn das Plugin es aber zuweist, hat man eine Supportanfrage weniger.

The value should be encoded in full but the integer conversion strips some info.

def en14(value):
    ret = bytearray([0])
    ret.extend(struct.pack('>f', int(value)))
    #suggestion: ret.extend(struct.pack('>f', value))
    return ret

It might be a good idea to put the functions into the unittest

Update jQuery to the last version 2.2.2
ich glaub bin da durcheinander gekommen,
smartvisu nutzt es :D

Starting the mail plugin gives the following error:
ERROR IMAP Method IMAP exception: 'IMAP' object has no attribute 'alive'
Putting a self.alive in the init function fixes the problem for me.

Sometimes I also get the error message:
IMAP: problem parsing message b'3428': 'NoneType' object is not subscriptable

As far as I could research a standard "except" instead of "except Exception as e" could fix the problem.

Hi!

Is it possible that with the newer develop releases (1.2.584) the sh.tools.ping() doesn't work anymore? I've been using the function quite alot and it always worked like this:
test=sh.tools.ping('www.google.at') # optional: 192.168.0.1 or 10.0.0.1
logger.info("Ping: {}".format(test))

When I now trigger this I always receive "False" no matter what URL or IP I use (also internal ones). A standard ping from the linux commandline works flawlessly.

Integration der Sunrise/ sunset/ altitude /azimut Berechnung als Standart-Items. Da viele Leute das Sowieso vorhaben könnte man das Standartmaessig auch integrieren.

The language settings dropdown in backend is broken since splitting the backend into multiple files (core, utils, blockly).

Choosing another language (english or french) works. But when returning to the service page the language dropdown always displays "German" as selected language. That also means that if you want to switch back from french or english to german the dropdown does not work because german is already selected. You then have to push the "reload" button to get back to german.

I did some debugging log and i think that in BackendCory.py, function services_html(self), the global translation_lang variable set in utils.py function load_translation(language) is not available.

I seems to be a translation_lang variable scope problem.

Sometimes when startin SmarthomeNG fresh I get the following error message. Doesn't seem to be a real problem but it's still an error ;)

2016-07-25 10:57:47 ERROR SQLite dump Method SQLite dump exception: dictionary changed size during iteration
Traceback (most recent call last):
File "/usr/smarthome/lib/scheduler.py", line 371, in _task
obj()
File "/usr/smarthome/plugins/sqlite/init.py", line 169, in _dump
for item in self._buffer:
RuntimeError: dictionary changed size during iteration

I wrote some common modules for my system and stored them in /lib/3rd. Please add the line in smarthome.py again.

Yesterday I started to install SmartHomeNG 1.2.435.dev (from the release-1.2 Branch) completly new. Only the Database and the Items are copied from my old smarthome.py installation.

My first Error was:

2016-07-24 19:22:41 DEBUG    __init__     Main         SQLite 3.8.7.1 -- __init__.py:__init__:61
2016-07-24 19:22:45 DEBUG    __init__     Main         SQLite: database integrity ok -- __init__.py:__init__:78
2016-07-24 19:22:45 ERROR    plugin       Main         Plugin sql exception: No module named 'plugins.sqlite.upgrade' -- plugin.py:__init__:67
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/plugin.py", line 63, in __init__
    plugin_thread = PluginWrapper(smarthome, plugin, classname, classpath, args, instance)
  File "/usr/local/smarthome/lib/plugin.py", line 108, in __init__
    exec("self.plugin.__init__(smarthome{0})".format(args))
  File "", line 1, in 
  File "/usr/local/smarthome/plugins/sqlite_visu2_8/__init__.py", line 93, in __init__
    import plugins.sqlite.upgrade
ImportError: No module named 'plugins.sqlite.upgrade'

I solved this Problem by changing the following lines in the init.py File:
Line 93 from

import plugins.sqlite.upgrade

import plugins.sqlite_visu2_8.upgrade

plugins.sqlite.upgrade.Upgrade(self._fdb, version)

plugins.sqlite_visu2_8.upgrade.Upgrade(self._fdb, version)

After the successful Upgrade and a smarthomeNG restart (the first with the DB Upgrade worked (the Charts in smartVISU worked also) this Error occurs:

2016-07-24 22:12:01 DEBUG    __init__     Main         KNX[default]: Item EG.Eingang.temperature is mapped to KNX Instance default -- __init__.py:parse_item:253
2016-07-24 22:12:01 DEBUG    __init__     Main         KNX[default]: EG.Eingang.temperature listen on 5/0/3 -- __init__.py:parse_item:260
2016-07-24 22:12:01 DEBUG    __init__     Main         KNX[default]: EG.Eingang.temperature listen on and init with 5/0/3 -- __init__.py:parse_item:269
2016-07-24 22:12:01 ERROR    item         Main         Item EG.Eingang.temperature: problem creating: __call__() got an unexpected keyword argument 'last_change' -- item.py:__init__:221
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/item.py", line 219, in __init__
    child = Item(smarthome, self, child_path, value)
  File "/usr/local/smarthome/lib/item.py", line 276, in __init__
    update = plugin.parse_item(self)
  File "/usr/local/smarthome/plugins/sqlite_visu2_8/__init__.py", line 146, in parse_item
    item.set(value, 'SQLite', prev_change=prev_change, last_change=last_change)
TypeError: __call__() got an unexpected keyword argument 'last_change'

I had found out that this error ist related to the positioning of my Items. Here an example:

Error:

[EG]
  [[Eingang]]
    [[[temperature]]]
      type = num
      sqlite = yes
      [[[[set]]]]
        type = num
        sqlite = yes
      [[[[state]]]]
        type = num
        sqlite = yes

No Error:

[EG]
  [[Eingang]]
    [[[Heizung]]]
      [[[[temperature]]]]
        type = num
        sqlite = yes
      [[[[set]]]]
        type = num
        sqlite = yes
      [[[[state]]]]
        type = num
        sqlite = yes

So somehowe the SQL Plugin doesn't work with Items which had child Objects with SQL.

Hopefully I could help you with my Explantation otherwise ask me in German.

Gegenwärtig haben wir unterschiedliche Lizenzheader, dies führt zu folgenden Situationen:

• Ungültige Einschränkungen für die GPL Version (z.B. AVM Plugin)
• In den Core Files wird nur der aktuelle Main Author genannt, nicht die Leute mit Contributions.

Eine mögliche Lösung hierfür:

• Lizenzheader Projektweit einheitlich
• Author der Projektdateien ist immer "The Smarthome.py Team"
• AUTHORS Datei im Projektroot hat eine Liste der Authoren
• Es werden nur noch neue Projektdateien gemerged wenn diese sich an den Standard halten (d.h. Erwähnung dieses Verfahrens im Contribution Guide)

Auf diese Art können wir Lizenzwildwuchs vermeiden, und haben alles an einer zentralen Stelle dokumentiert.

When starting up the Init message has a wrong time stamp (2 hours earlier). In the log here 21:11:01 should be 23:11:01

2016-08-03 22:11:22 WARNING Main Client 10.0.0.27:64410 requested invalid item: licht.eg.gang.sperren
2016-08-03 21:11:01 WARNING Main -------------------- Init SmartHomeNG 1.1.448.dev --------------------
2016-08-03 23:12:30 WARNING Main Client 10.0.0.27:58735 requested invalid item: licht.eg.bad.spots.sperren

Hi there!

The fader function works like this right now: It fades a specific item from value x to z - but immediately stops fading when the value of the item gets changed "from outside".

That's useful to interrupt the fade by clicking on a KNX switch. But it's very problematic when a KNX actuator constantly sends the actual value after a change. Because this received value stops the fading process. Only solution right now is to delete the knx_receive attribute from the specific item (i.e. a light)

It would be perfect if the fader only interrupts the fading process when a value is received from a specific source. Let's say a switch has KNX:1.1.10 and the actuator hast KNX:1.1.1. Stopping the fade of lamp XYZ should only happen when the source of the valuechange is KNX:1.1.10

offline's Autoblind plugin features such a logic. If it's too complicated maybe just disabling the fade interrupt would also help in most cases I guess (or making this an option in the function)

Thanks alot, hope it was somehow understandable ;)

line 392 <<<<<<< HEAD
line 404 =======
line 413 >>>>>>> a864039

Same problem several lines below.

Or is that just a local github problem?

Could you please update the operationlog plugin to this release here?
https://github.com/JanT112/smarthome/tree/feature-operationlog-plugin-add-itemlogtext

Thanks!

Only some small adaptions seem to be necessary to create a multiclick option for KNX switches:
https://knx-user-forum.de/forum/supportforen/smarthome-py/36050-taster-doppelklick-via-logik

Would love to see this implemented in item.py

Plugins werden in der Plugin-Konfiguration konfiguriert, die diverse Einstellungen fuer ein Plugin enthalten kann. Diese Einstellungen werden dem Konstruktor des Plugins uebergeben, werden wobei das Mapping zwischen der Einstellung und des Konstruktor-Parameters ueber den Namen gemacht wird: enthaelt die Konfiguration den Wert host so muss der Konstruktor auch einen Parameter host besitzen. D.h. alle moeglichen Parameter muessen als Konstruktor-Parameter angeben werden, damit sie verwendet werden koennen. Weiterhin muss das Plugin sich auch um die Typenbehandlung kuemmern (z.B. int(param) oder bool(param)).

Ziel soll es sein, ein einfaches generisches Interface fuer Plugin-Einstellungen zu schaffen, die verschiedene Arbeiten abnehmen kann.

Folgende Punkte koennten interessant sein:

• fehlerhafte Parameter werden ignoriert und fuehren nicht direkt zu einem Fehler (siehe #55)
• es soll eine Parameter-Konfiguration im Plugin hinterlegt werden koennen, die die moeglichen Parameter definiert
• die Typenbehandlung (Umwandlungen von z.B. str in int) soll automatisch passieren
• evtl. kann eine Parameter-Konfiguration auch dazu genutzt werden um diese in die Dokumentation (automatisch) einfliessen zu lassen
• verschiedene Typen koennten direkt unterstuetzt werden (z. B. den Typ "password", welches sich auch um die Hashes kuemmern koennte - siehe dazu die Dikussion aus #101)
• die Dokumentation der Plugin-Parameter in der Doku koennte standardisiert und automatisiert generiert werden
• ...

Hi René,

ich hatte die schon geschrieben, dass ich mit dem Erkennen von Devices anhand der Mac Adresse Probleme hatte. Ich habe das Thema auf die Firmware Version der Box eingegrenzt.

Das Problem besteht weiterhin auf der 7390 v6.30, während die Erkennung auf der 7390 v6.51 funktioniert.

Kann ich für Dich noch irgendwas nachschauen, damit Du das besser eingrenzen kannst?

Viele Grüße
Martin

see https://knx-user-forum.de/forum/supportforen/smarthome-py/934835-avm-plugin/page13

capital letters in the instance attribute seem to be changed to non-capital letters. e.g.:

"Der Underline ist kein Problem.
Auch die Groß-Kleinschreibung in der plugin.conf ist kein Problem.
Sobald ich jedoch in der items.conf im instance "_EG" schreibe, funktioniert die Aktualisierung der items nicht.
die Kombi "_EG" in der plugin.conf und "_eg" in der items.conf klappt aber problemlos.

--> Grossbuchstaben in der items.conf haben mein Problem verursacht."

I just started to create new PR for some of my enhancements implemented in the old project and want to know which PR are also interesting. I suggest to list them all in this issue.

Currently interesting PR which should be merged into smarthomeNG:

• CLI Plugin: List items matching a pattern - mknx/smarthome#44 -> #46
• New CLI command: dump - mknx/smarthome#138 -> #48
• Issue 59: Support crontab ranges 'x-y' and 'x/y' - mknx/smarthome#61 -> #49
• Add plugin methods to smarthome - mknx/smarthome#81 -> #50 / implemented in a diferent way
• Remove trigger from items - mknx/smarthome#166 -> #51
• CLI: Scheduler commands - mknx/smarthome#148 -> #103
• New "ld" (log dump) command for CLI - mknx/smarthome#93 -> #103
• CLI Plugin: Allow other plugins to add custom commands - mknx/smarthome#182 -> #103
• Support for multiple KNX Interfaces. - mknx/smarthome#124 (obsoleted by #50, but implementation should be updated)
• Make it possible to attach items to a given plugin - mknx/smarthome#83 -> #53
• Add some tests for lib.config - mknx/smarthome#89 -> merged by @cstrassburg
• Make it possible to match on item attribute and it's value - mknx/smarthome#175 -> #80
• Line continuation in config files - mknx/smarthome#167 -> #81
• iCal plugin: Calendar registry and item configuration - mknx/smarthome#58 -> #84
• Attach logic trigger methods for plugins - mknx/smarthome#142 -> #106
• Disable / enable logics - mknx/smarthome#137 -> #108
• Be able to change dicts/lists via CLI plugin - mknx/smarthome#165 / #118
• DB API2 support in SmartHome.py used in SQLite plugin - mknx/smarthome#69 -> #131

Hi there!

Since one of the last releases (develop 1.3) I sometimes get the error message
Database: update_item - Unable to acquire database lock (2)
I have no idea what it means and how I can avoid it. Didn't change anything else since 1.2 where the plugin ran without any issues.

A user reports here
https://knx-user-forum.de/forum/supportforen/smarthome-py/980966-feature-vorschlag-custom-dpts-in-knx-plugin that he is running on TEBIS system which encodes its DPT in a strange way. It won't make sense to support all custom implementations but it might be well possible to have a kind of plugin for the knx plugin.
Another question is how to support packed knx data types within a single item. This might be easy for example for a four byte value that implements an RGB value but can be complicated for an item that uses two bytes to include a packet information structure. Any ideas?

#31

Please generate an error when a digit is encountered in an item parsing.
e.g. item names [1w_Bus], [42] or [_Bus]

Maybe also item names like [and], [class], [def] etc. should be avoided, since they are reserved python names.

It would be great, if it would be possible to reference items with a relative reference.

This could be helpful especially for eval and eval_trigger entries in the etc/item.conf file but also for other entires (eg. sv_widget). This way it would be much simpler to copy parts of the item config structure.

The relative references should be converted to absolute references while loading the item.conf file. This way, all other item handling in SmartHomeNG can be left unchanged.

Newest version 2.5 , used version 2.0
Lib/3rd/dateutil

Hallo zusammen,

um etwas den Wildwuchs zu verhindern, habe ich angefangen, einen Bereich für Entwicklungs-Guidelines anzulegen:
https://github.com/smarthomeNG/smarthome/wiki/Entwicklungs-Richtlinien

Die Dinge sind nicht in Beton gemauert und ich würde bitten a) neue Vorschläge hier zu äußern b) wenn Probleme mit den bestehenden sind, diese ebenfalls hier zu diskutieren.

When items are parsed within the knx plugin that do not have knx_dpt then the parsing is already done.
We should however consider to first check any other knx_... entries first and just when the datapoint was forgotten to raise a warning or an error.

Lg webOS Plugin
https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/geb%C3%A4udetechnik-ohne-knx-eib/823383-ip-control-der-neuen-lg-webos-tv-s/page2

https://github.com/ubaransel/lgcommander/blob/master/lg_2012_commander.py

https://github.com/msloth/lgtv.js

Hi!
When I start the datalog plugin without additional parameters everything works fine. As soon as I uncomment the standard parameters for filepatterns and logpatterns I get the following error message:

2016-08-01 13:46:24 ERROR plugin Main Plugin datalog exception: string indices must be integers -- plugin.py:init:67
Traceback (most recent call last):
File "/usr/smarthome/lib/plugin.py", line 63, in init
plugin_thread = PluginWrapper(smarthome, plugin, classname, classpath, args, instance)
File "/usr/smarthome/lib/plugin.py", line 108, in init
exec("self.plugin.init(smarthome{0})".format(args))
File "", line 1, in
File "/usr/smarthome/plugins/datalog/init.py", line 56, in init
ext = self.filepatterns[log].split('.')[-1]
TypeError: string indices must be integers

The cyclus between two calculations of the suns position is too long. Right now it is calculated every 30 minutes. That means e.g. an azimuth change of more than 10° which is too much.

[env_loc]
    filename = location.py
    crontab = init | sunrise+1m | sunset+1m | sunrise-5 | sunset-7
    cycle = 1800

I would suggest to decouple the sunrise/sunset functions into one script which will be executed just around sunrise/sunset times and shortly afterwards. And then put two further scripts into the game, one for azimuth and one for elevation.
The one for azimuth should update the azimuth every two minutes, this way we can keep the angle deviation below 1°.
The one for elevation should update the elevation every five minutes so to keep the angle deviation below 1°.

And furthermore which might be even more important: The script uses the smarthome sun object to do the calculations. When modifying the UZSU plugin I needed to create a new sun object since sharing it with the rest of SmartHomeNG can yield very strange and unexpected results.

#relevant code is here:
        # create an own sun object:
        try:
            #longitude = self._sh.sun.long
            #latitude = self._sh.sun.lat
            #elevation = self._sh.sun.elevation
            longitude = self._sh.sun._obs.long
            latitude = self._sh.sun._obs.lat
            elevation = self._sh.sun._obs.elev
            uzsu_sun = lib.orb.Orb('sun', longitude, latitude, elevation)
            self.logger.debug("Created a new sun object with latitude={}, longitude={}, elevation={}".format(latitude, longitude, elevation)) 
        except Exception as e:
            self.logger.error("Error '{}' creating a new sun object. You could not use sunrise/sunset as UZSU entry.".format(e))
            return

Currently, it seems that instance specific information is not available in the plugin specific init-method. This is a problem as e.g. plugin-specific subthreads (as the CallMonitor in AVM) can be created in the init-method and need these information.

i think the behaviour is bound to PluginWrapper, where init is called before setting the instance name

class PluginWrapper(threading.Thread):
    def __init__(self, smarthome, name, classname, classpath, args, instance):
        threading.Thread.__init__(self, name=name)
        exec("import {0}".format(classpath))
        exec("self.plugin = {0}.{1}(smarthome{2})".format(classpath, classname, args))
        setattr(smarthome, self.name, self.plugin)
        if isinstance(self.get_implementation(), SmartPlugin):
            if instance != '':
                logger.debug("set plugin {0} instance to {1}".format(name, instance ))
                self.get_implementation().set_instance_name(instance)
            self.get_implementation().set_sh(smarthome)

Hi René,

beim Callmonitor (Incoming) ist mir ein Verhalten aufgefallen, das das Plugin von dem Einbau der eigenen Telefonnummer nicht hatte.

Im Widget geht das Icon auf "Gespräch" (oranger abgenommener Hörer), aber die Angaben zu Namen, Zeit und Nummer bleiben unverändert auf dem alten Anruf. Das ändert sich auch nach Beendigung des Telefonats nicht. Es werden weiterhin die Daten des nun vorletzten Anrufs angezeigt.

Nach einem Neustart von smarthome.py werden die korrekten Daten über den letzen Anruf angezeigt.

plugin/skeleton and dev/skeleton schould be merged. Maybe move plugin/skeleton into dev?

Ich lese mit dem MBUS Plugin und IR Leseköpfen 4 Wärmemengezähler aus - klappt auch super, allerdings passiert es von Zeit zu Zeit, dass bei einem Neustart von Smarthome.py ein Treiberfehler auftaucht, den ich nicht wegbekomme (unable to enable UART). Ich vermute es liegt daran, dass das Plugin in der Startphase geladen wird und die WMZ auslesen will, da das System in der Startphase ausgelastet ist, gibt es anscheinend Fehler in der Kommunikation und die Leseköpfe klinken sich danach aus (und lassen sich nur durch ein - und ausstecken des USB-Steckers wieder aktivieren -> extrem unsmart).
Ich würde nun das Plugin gerne verzögert starten lassen, also nicht zu Beginn von Smarthome.py sondern z.B. erst nach 120 Sekunden - ist das Möglich (Ich könnte in das Plugin zu Beginn ein time.sleep enfügen - das finde ich aber wenig elegant.

Man könnte eine allgemeine Feiertagsberechnung implementieren wie sie hier
http://www.stephanjohn.de/blog/2011/jan/07/berechnung-von-feiertagen/
beschrieben ist, sodass man in den Rollladenskripten auf if sh......item_feiertag() prüfen kann