Integration von MySensors in FHEM geplant?

[gloob]

Ich habe gerade auch das neue Modul getestet. Bei mir werden die readings eines neuen Sensors auch falsch angelegt.
Scheinbar ist mit der neuen version wirklich etwas falsch.

[hexenmeister]

Ich meine zu wissen, wo der Hase im Pfeffer liegt. Mal bitte ohne Autocreate probieren (würde ja selbst machen, passt aber gerade schlecht).

[gloob]

Alle Sensoren die ich vor der neuen version angelernt habe, funktionieren ohne Probleme. Es scheint also wirklich am Create zu liegen

[hexenmeister]

Dann ist der Fall klar, Hauswart sollte sich das mal ansehen. Vlt. schaue ich mir das auch an, komme aber nnicht so schnell zu.
Workaround: Autocreate aus, Konfig per Hand anlegen.

[Erdschluss]

Im GUI kennt autocreate nur 1, also einfach löschen?
Oder gibts da nen impliziten Defaultwert !=0?

[hexenmeister]

Ja, Attribut "autocreate" soll weg.

[Erdschluss]

Ich kloppe mich noch etwas mit dem Attribut-Editor, aber ein "tripped" kommt schon mal durch 

[ntruchsess]

Hab glaube ich einen Fix für das Autocreate-problem. @Hauswart hat S_LIGHT als Alias für das neue S_STATUS drin gelassen, das bringt aber die Datenstrukturen für das Autocreate durcheinander in Folge verschieben sich die Devicetypen, die in den Messages ja numerisch übertragen werden um eins, dadurch bekommt Autocreate dann die Mappings für den danebenliegenden Devicetyp.

Das hat auch zur Folge, dass man vorhandene Attribute 'mapReadingType_LIGHT' durch 'mapReadingType_STATUS' ersetzten muss.

[gloob]

Kann es sein, dass es seit heute wieder ein Update gibt?

Nach einem ersten Kurztest per Remoteverbindung, scheint es jetzt die Readings wieder richtig anzulegen.
Ich muss nur noch einmal Testen ob jetzt auch die Node ID wieder richtig gesetzt wird.

[Hauswart]

Hallo Zusammen, ich war leider von Samstag bis gestern Nachmittag weg und konnte daher nicht eingreifen.

Danke Norbert für den Fix... Da laut API-Definition ist komischerweise S_LIGHT und S_BINARY für den gleichen Wert zuständig?
http://www.mysensors.org/download/serial_api_15

[hexenmeister]

laut API-Definition ist komischerweise S_LIGHT und S_BINARY für den gleichen Wert zuständig?
http://www.mysensors.org/download/serial_api_15

Naja, das von der Logik passt schon, beides ist eben 1 oder 0 vs. ein oder aus.

[Hauswart]

Naja, das von der Logik passt schon, beides ist eben 1 oder 0 vs. ein oder aus.

Ich meine, dass beide für Value 3 zuständig sind? Aus meiner Sicht kann nur eine Variable dafür zuständig sein. Hatte mich unglücklich ausgedrückt mit "Wert".

[hexenmeister]

Ich meine, dass beide für Value 3 zuständig sind? Aus meiner Sicht kann nur eine Variable dafür zuständig sein. Hatte mich unglücklich ausgedrückt mit "Wert".

Habe ich schon verstanden. Wäre sicher für die Presentation-Message von Vorteil. Von dem funktionalem Gesichtspunkt jedoch gleichwertig.

[ntruchsess]

ich glaube ich muss meinen Fix heute abend noch mal überarbeiten. So wie es jetzt implementiert ist, sollte autocreate funktionieren - Was bisher als S_LIGHT angelegt worden wäre, erzeugt jetzt halt jetzt ein S_STATUS. Soweit kein Problem (für neu angelernte Sensoren bzw. wenn Autocreate angeschaltet ist).

Nur wenn man schon existierende MYSENSORS_DEVICE definitionen unter Verwendung des mapReadingType_LIGHT-Attribut hat, wird es mit der letzten Änderung wohl auf die Nase fallen (Weil es den String 'LIGHT' in dem Attribut nicht mehr erkennt - das ist generisch implementiert und der String ist ja jetzt draußen aus der Constants.pm).

[Erdschluss]

Nach Update und Neustart liefert der Sensor jetzt auch plausible Werte 
Juhu!