Ankündigung: Update auf MySensors 2.0 API - alive usw. geändert!

[Beta-User]

Wäre nett, wenn ein paar Leute Rückmeldung geben könnten, ob das soweit fehlerfrei läuft, ich habe aktuell keine Node im Einsatz, die smartSleep nutzt, und bei den normalen Nodes scheinen keine Probleme aufzutreten.

Ein download?!?

Kein Interesse vorhanden oder volles Vertrauen? (Zur Beruhigung: läuft bei mir seit vor dem Publish hier ohne erkennbare Probleme...)

[PeMue]

Ein download?!?

Gerade leider keine Zeit, um das zu testen, sorry.

Gruß Peter

[alru]

Ein download?!?

Hab derzeit keinen Anwendungsfall, den müsste ich mir erst konstruieren. Das passt zeitlich allerdings derzeit nicht.
Werde es bei Gelegenheit aber installieren und regressiv testen.

...nicht verzagen!!!

[tmandel]

Danke für deinen Patch. Bei mir laufen zumindest auch die vorhandenen Nodes sauber durch.
Mein Smartsleep Node liegt noch auf dem Schreibtisch und wartet darauf in die Ikea Stranne Lampe "gehackt" zu werden.
Das abbrechen der SmartSleep Schleife, wenn nach I_PRE_SLEEP_NOTIFICATION ein Einschaltbefehl kommt läuft auch sauber durch.

Nachts wenn die Lampe aus ist, sinkt die Leistung auf 0,15W durch Smartsleep (ohne waren es ca. 0,8W).
Das macht ca. 1,70€ pro Jahr, was nicht viel ist. Aber die Anzahl meiner Nodes wächst.

[Beta-User]

Na immerhin ein paar Rückmeldungen, Danke .

Ich denke, ich werde das einfach ausrollen

Es gibt mindestens einen, der auch keine Probleme hat bzw. es im Testbetrieb hilfreich findet - und die Erweiterungen betreffen eh' smartSleep(), das Risiko, dass was danebengeht, ist also sehr begrenzt...

Zur Info:
Im Moment beschäftigt mich das Thema SetExtensions/AttrTemplate etwas im Zusammenhang mit MySensors, das würde ich gerne wieder zum Laufen bringen mit "on-for-timer" usw.. Ich hatte zu SetExtensions auch mal einen Thread angefangen, aber keine Rückmeldung erhalten. Geht darum ob jemand was dazu sagen kann, ob das jemals funktioniert hat und wenn ja, seit wann es nicht mehr funktioniert. Das würde mich nach wie vor noch interessieren, ich selbst habe das @MySensors nie genutzt .

Jetzt wäre es m.E. eine schöne Sache, die neuen Features (auch mit mehreren Icons usw. ohne Perl-Code) wenigstens für ein paar Beispiele aus dem MySensors-Baukasten bereitzustellen, daher: Wer eine Idee hat, was da anzupacken ist: her damit...

Ich will das aber nach Möglichkeit dann nicht mit dem smartSleep-Ergänzungscode mischen.

Gruß, Beta-User

[SirBen]

Moin,
ich habe aktuell das Problem, dass der Status nicht auf Alive wechelt.
Mein Mysensors Sketch beinhaltet den sendHeartbeat() befehl und dieser wird regelmäßig ausgeführt (alle 5 minuten).
Die Temperaturwerte kommen auch alle 5 minuten.
In FHEM werden die Temperaturen aktualisiert, state bleibt dead.
Ich habe mal verbose auf 5 gestellt und festgestellt, dass kein Heartbeat zu finden ist. Daher schließe ich daraus, dass Mysensors den heartbeat nicht sendet.
Nur was mache ich falsch?
Ich verwende einen Nano mit Ethernet schnittstelle als Gateway, an dem auch die Temperatursensoren hängen.
Können etwa nur die Nodes (ich habe keine Nodes) einen heartbeat senden?
Oder muss in FHEM ein reading hinzugefügt werden? Ein heartbeat-reading gibt es jedenfalls nicht im device.
Außer "sendHeartbeat();" habe ich am Mysensors Sketch nichts hinzugefügt, was mit heartbeat zu tun hat.

Vielen Dank schon mal.
LG

[Beta-User]

Hm, also:
Ein GW ist immer auch eine Node (MYSENSOR_0). Wenn in der loop() ein sendHeartbeat() drin ist, sollte der also auch in FHEM ankommen. Das Problem mit GW's ist halt, dass für mehrere GW's nur ein MYSENSOR_0 exisitert, in den alles wandert, was von irgend einem GW kommt.

Was ich mir im Moment denken könnte: die GW-Messages sind auch dazu da, um zu prüfen, ob ein reconnect sinnvoll ist; könnte also sein, dass der heartbeat von einem GW nie im GW-Code ankommt; wenn das so ist, könnte man das vermutlich schon ändern, aber ob es Sinn macht? An sich würde ich - wegen dieser Vermischung aller Informationen - immer empfehlen, die GW- und Nodefunktionalität zu trennen.

Muß ich mir ansehen, kann aber dauern. Einstweilen kannst du die eine Zeile wieder aktivieren (alive bei jeder Reading-Aktualisierung), wie im Eingangspost beschrieben.

[SirBen]

Vielen Dank für die super schnelle Antwort.
Ich habe die Zeile 683 reaktiviert. Alive geht erstmal wieder.
Wäre natürlich klasse wenn du in den Tiefen des GW-Codes was finden würdest.
LG

[Beta-User]

Wäre natürlich klasse wenn du in den Tiefen des GW-Codes was finden würdest.

Yup, die heartbeat-messages für die "0" werden anders behandelt.
Vorschlag: das GW bekommt ein weiteres setzbares Attribut ("forwardGWHeartbeat:0,1"). Ist das gesetzt, wird der heartbeat zusätzlich auch an "MYSENSOR_0" weitergegeben?

(Aber nochmal: eigentlich ist es keine sooo tolle Idee, in FHEM die Node 0 zu strapazieren...)

[SirBen]

Vorschlag: das GW bekommt ein weiteres setzbares Attribut ("forwardGWHeartbeat:0,1"). Ist das gesetzt, wird der heartbeat zusätzlich auch an "MYSENSOR_0" weitergegeben?

Damit wäre ich mehr als zufrieden. Ein sehr guter Vorschlag.

[Beta-User]

...kann aber etwas dauern mit dem heartbeat, und wie gesagt, bei mehreren GW's hört der "Spaß" ziemlich bald auf...

[SirBen]

Oder wäre es einfacher ein Attribut hinzuzufügen welches den die alte Alive Funktion wieder aktiviert?
Z.B. AliveOnUpdateReading:0,1?

[Beta-User]

@all:
Bin noch nicht sicher, aber nach der Diskussion mit Rudi die Tage zu SetExtensions neige ich dazu, eventuell die alive-Geschichte aus dem "state" in das Reading "heartbeat" zu verlagern. Das böte vielleicht die Möglichkeit, EIN schaltbares Reading für state zu "verwenden" und für dieses dann "on-for-timer" usw. bereitzustellen. Für mehrkanalige müßte man weiter auf ReadingsProxy & Co ausweichen, aber z.B. dimmbare Lampen wären so ggf. einfacher zu handhaben.
Vielleicht verratet ihr mir eure eine Meinung dazu? Das wäre ein größerer Aufwand, den ich nur unternehmen würde, wenn es a) Leute gibt, die das gut finden und b) nicht zu viele, die das nicht gut fänden...

@SirBen
Das Attribut wäre vielleicht einfacher, aber in jedem Fall "kostspieliger", daher hatte ich diese Option bereits bei der Auslieferung der Aktualisierung verworfen.
Im Moment habe ich noch eine andere, weitergehende Idee:
Ein "mapNode0"-Attribut.
Damit könnte man vielleicht sogar die Readings jeder GW-Node separat halten... Ist aber evtl. auch "kostspielig", muß ich mir ansehen...

[SirBen]

Im Moment habe ich noch eine andere, weitergehende Idee:
Ein "mapNode0"-Attribut.
Damit könnte man vielleicht sogar die Readings jeder GW-Node separat halten... Ist aber evtl. auch "kostspielig", muß ich mir ansehen...

Klingt auch seht gut.
Würde das bedeuten, dass alle Readings von der MYSENSOR_0 in ein extra Reading gemappt werden? Oder ein extra Device?

Was meinst du mit "kostspielig"?

Vielleicht verratet ihr mir eure eine Meinung dazu? Das wäre ein größerer Aufwand, den ich nur unternehmen würde, wenn es a) Leute gibt, die das gut finden und b) nicht zu viele, die das nicht gut fänden...

Ein heartbeat reading würde ich gut finden. Es sei denn das würde trotzdem nicht beim Node0 funktionieren 

[Beta-User]

@SirBen,
ich nehme mal an, du magst den Tester spielen...

Anbei eine etwas erweiterte Version vom IO-Modul. Gibt da ein neues Attribut mapNode0Id, bitte nicht irritieren lassen vom jetzigen Format der auswählbaren Optionen, dieses am GW einfach auf 0 setzen sollte genügen.

Danach sollte der MYSENSOR_0 (timeoutAlive sinnvoll gesetzt) sich "normal" verhalten; du brauchst auch im GW-Sketch keine extra heartbeat-Sendeanweisung, für GW's fordert der Code in 00_MYSENSORS sowieso regelmäßig (alle 5 Min oder so) einen an.


Kostspielig meint: es macht einen Unterschied, ob man ein Reading bei jeder anderen Reading-Aktualisierung mit pflegt oder das nur auf bestimmte Messages begrenzt.


Die Idee mit dem Mapping will sagen: Neues Device, in dem dann (exklusiv) alle Infos landen, die diese GW-Node betreffen; MYSENSOR_0 bliebe dann z.B. einem anderen GW überlassen.
So könnte man mehrere "aktive" GW's haben (sonst landet halt alles in der einen Node, und man kann nur eine Node steuern, also irgendwas anschalten oder Informationen hinsenden).