Vorarbeiten: Update auf MySensors 2.0-API

[Beta-User]

Hallo zusammen,

mit dem morgigen Update wird eine aktualisierte Constants.pm ausgeliefert. Diese dient dazu, einige Neuerungen, die mit der MySensors API 2.0 eingeführt wurden, jetzt auch in FHEM verfügbar zu machen.

In der Umsetzung ist allerdings noch manches offen, es werden Tester benötigt und zu manchem dürft ihr auch vorab eure Meinung äußern, wie es letztendlich umgesetzt werden soll. Da die Koordination dieser Dinge einen gewissen Aufwand erfordert, den Hauswart derzeit aus sehr erfreulichen privaten Gründen nicht leisten kann, haben wir uns auf ein arbeitsteiliges Vorgehen verständigt.

Anbei findet ihr daher eine Testversion der 10_MYSENSORSDEVICE.pm. Diese sollte nach den bisherigen Erfahrungen ohne weiteres und ohne wesentliche Einschränkungen im gewohnten Umfang lauffähig sein, die neuen Funktionen müssen (teilweise) erst noch getestet werden - eine Funktionsgarantie gibt es aber selbstverständlich wie immer nicht.

Was allerdings anders ist, ist die Benennung des battery-Readings. Entsprechend dem Beitrag im Developer-Bereich (https://forum.fhem.de/index.php/topic,87575.0.html) ist der Name dieses Readings zukünftig "batteryPercent" - hier ist also "action required", man kann die alte Funktionalität aber übergangsweise bei Bedarf noch recht einfach wieder aktivieren.

Nun zu den eigentlichen Neuerungen:

- heartbeat
Status: getestet und (ausgelöst über die FHEMWEB in der Detailansicht der Nodes) funktional
-- Sendet eine Node ein heartbeat(), wird das alive-Reading aktualisiert. Es wird empfohlen, beim Programmieren der Nodes, die auf "alive" überwacht werden sollen, darauf zu achten, dass diese einen heartbeat (oder smartsleep-Signal) senden (s.u.).
-- Es gibt ein neues "get", mit dem eine Node auch aktiv "angepingt" werden kann - damit kann man also prüfen, ob die Kommunikation von und zu einer Node derzeit steht.
-- Das ist nicht-triggernd realisiert, man muß also den Browser-refresh ausführen, um den aktualisierten Zeitstempel zu sehen. (soll m.E. so bleiben, ggf. kann man das noch über den Aufruf steuern, kommt evtl. noch)
-- Effektiv glaube ich, es wäre besser, das "alive"-Reading zukünftig nur noch bei updates von internen Messages (heartbeat und smartsleep, s.u.) zu aktualisieren. Das mindert die Systemlast bei den übrigen, die die Funktionalität gar nicht nutzen wollen. (Meinungen erbeten!)
EDIT: ist jetzt so umgesetzt, die Zeile ist auskommentiert noch im Code enthalten und kann bei Bedarf wieder manuell aktiviert werden => Ausbau, wenn kein Widerspruch kommt.
-- Macht man das ganze über die Kommandozeile, erscheint ein leeres Dialogfeld - gefällt mir noch nicht...
EDIT: läßt sich bei get nicht verhindern (auch bei anderen neuen get's) => habe ich so belassen, da mir die Logik, dass man sowas aktiv anfordert als "get" besser gefällt .

- RSSI
Status: grob getestet (via FHEMWEB-Button), aber mangels eigener RFM-Nodes keine Info, ob in wirklich funktional
-- erfordert aktive Anfrage via neuem "get" oder und entsprechenden Code auf der Node (MY_SIGNAL_REPORT_ENABLED)
-- macht nur bei RFM-Nodes Sinn (soweit bekannt)
-- ebenfalls nichttriggernd - kann bei entsprechendem Wunsch auch anders gemacht werden
-- die Richtung, also die Zuordnung der beiden Readings, die es geben sollte, ist geraten - wer da valide Info hat: her damit.
-- leeres Dialogfeld, wenn über Kommandozeile (das hätte ich noch gerne anders, dazu muss aber noch etwas Arbeit rein... Der Aufruf muß erst an die Node raus und die Rückmeldungen ausgewertet werden; dazu benötige ich aber erst mal welche )
EDIT: Es wird eine Art Schleife aufgerufen, die alle möglichen Werte nacheinander abfragt; gehen zwischenzeitlich Nachrichten verloren, muß das neu angestoßen werden, sonst gibt es ein internal, das anzeigt, auf welcher Stufe der Prozess gerade steht. Ist der länger unverändert, ist die Anforderung im off gelandet...

- smartsleep
Status: fast ungetestet, aber vorhandene ssmartSleep-Nodes scheinen auch keine ernsthafte Gefahr für die Stabilität von FHEM zu sein.Ich hoffe zwar nicht auf echte Schwierigkeiten, aber dennoch bitte vor der Verwendung ein Backup der seitherigen pm bereit halten und ggf. zurückspielen. Der Teil ist auch Perl-mäßig eine echte Herausforderung - wenn also jemand der Perl-Experten da einen kritischen Blick drauf werfen würde, wäre das nett *smile*
-- Status wach/schlafend sollte sichtbar sein (nichttriggernd, kann geändert werden, bei Bedarf über Attribut?)
-- Ziel ist es, auch Sendebefehle an die Node in eine Queue zu schreiben und auszuliefern, sobald die betr. Node aufwacht. Das könnte miot etwas Glück sogar schon funktionieren - Testergebnisse wären nett, ich mach bei Gelegenheit auch mal den einen oder anderen Test...
EDIT: Das funktioniert soweit, allerdings ist bei Nicht-ACK-Nachrichten nicht auszuschließen, dass Messages verloren gehen, gerade bei solchen Nodes, die über einen Repeater angesprochen werden. Hängt von den konkreten Umständen ab. Ggf. hilft es bei Problemen, die Zeit bis zum Einschlafen der Nodes zu verlängern (MY_SMART_SLEEP_WAIT_DURATION_MS).
ToDo: Gelegentich wird bei gleichzeitigem zeitverzögertem Senden der asleep/awake-Status nicht sauber aktualisiert.

Was die Namen der diversen Readings angeht, können die ggf. auch noch angepaßt werden.

Eure Rückmeldungen (und ggf. Mitarbeit!) sind also willkommen, bei neuen Erkenntnissen werde ich den Post bzw. Anhang dann aktualisieren. Sobald das insgesamt oder in wesentlichen Teilen ausgetestet ist, erfolgt dann der Rollout, ggf. auch in Etappen.
Wer mag, kann sich die Constants.pm natürlich auch direkt schon aus dem SVN holen .
Grüße,

Beta-User

EDIT: Neue Versionen angehängt, Details sind dem Thread zu entnehmen bzw. werden nachgereicht
Sonstige Neuerungen, soweit bisher nicht im obigen Text erwähnt:- OTA-Funktionalität eingebaut (Danke an Wallmeier!) - kann sehr langsam sein für nRF-Nodes@2.3.0, dann bitte das GW und evtl. Repeater-Nodes auf 2.20 downgraden, siehe hier.
- MY_SPECIAL_DEBUG kann genutzt werden (Abfrageschleife wie RSSI, s.o.)
- Kommentare bei der Presentation können in die Reading-Namen eingebaut werden, das ganze wird durch ein "get" angestoßen, wie hier beschrieben:

dass standardmäßig das bisherige Naming stattfindet und ein weiteres "get" einzubauen. Stößt man das an, soll geprüft werden, ob die aktuelle Namensgebung mit der sich aus Kommentaren ergebenden zusammenpaßt und ggf. dann das Naming angepaßt werden. Das hat den weiteren Vorteil, dass man auch Abweichungen ins Log schreiben und damit - zumindest nach einer weiteren Prüfung - auch Inkonsistenzen wie die in #42 aufdecken bzw. korrigieren kann.

Hier funktioniert das Löschen der bisherigen Reading-Namen noch nicht...

EDIT2: per svn verfügbare Dateien aus dem Thread gelöscht

[Ranseyer]

Ich bin dabei (wie besprochen) zu testen.
(Und habe hiermit auch diesen Faden abonniert)

[dirkcx]

Ich teste auch gerne mit. Ist geplant irgendwann eine OTA Funktion über fhem einzubauen?

[Beta-User]

Dann willkommen an Bord!

Sofern ihr bereits gestern die Dateien eingespielt habt: Bitte darauf achten, dass ihr nach einem (ersten) Update vermutlich wieder die "alte" 10_MYSENSORS_DEVICE.pm erhaltet. Diese muß dann wieder durch die aus dem ersten Post ersetzt werden.

Was OTA angeht: "geplant" würde ich nicht behaupten wollen. Ist im Moment oberhalb meiner Fähigkeiten, aber wenn's jemand beisteuert, kommt das gerne rein! Noch gerner, wenn jemand einen OTA-Bootloader für HardwareSerial und ATMega328 (und ATMega32U4) bauen würde ... Dann könnte ich auch meine RS485-Nodes bequem updaten, dann wäre das "veraltete" "alpha" schneller weg.

@Ranseyer:
Ich vermute ein Kommunikationsproblem auf der Funkstrecke. Die grundsätzliche Funktionalität des "get ... heartbeat" kannst du auch mit anderen GW/Nodes-Kombinationen testen, und ein nichtssagender RSSI-Wert von -256 kam bei mir, solange die Abfrage auf ne "-256" noch nicht drin war. Zum Testen kann man also ggf. die Abfrage aus den Zeilen 676 und 682 (" if ($msg->{payload} ne "-256" )")  löschen, dann sollte jede ansprechbare Node irgendwas zurückmelden (aber nur einen Wert).

Verwendest du den neuen oder alten Driver? Versuch's ggf. mal mit dem anderen (muß aber auf GW und Node)!

[Ranseyer]

Ich verwende immer diese Konfig beim RFM69:

#define MY_RADIO_RFM69
#define MY_IS_RFM69HW // Lokale Vorschriften beachten !
#define MY_RFM69_FREQUENCY RFM69_868MHZ
#define MY_RFM69_NEW_DRIVER

[Ranseyer]

Neu: alles auf die Testumgebung umgezogen, und deinen Dev-Stand (4 Files) aufgespielt und Owner gesetzt.
=> Alles wie auf dem Produktivsystem: Der Motionsensor conected sich und liefert fleissigst Daten.



Nun GW (und Node!) mit Debug und nicht mit neuem Treiber kompiliert:

Code Auswählen Erweitern

0;255;3;0;9;0 MCO:BGN:INIT GW,CP=RRNGA---,VER=2.3.0
0;255;3;0;9;12 TSM:INIT
0;255;3;0;9;20 TSF:WUR:MS=0
0;255;3;0;9;28 TSM:INIT:TSP OK
0;255;3;0;9;36 TSM:INIT:GW MODE
0;255;3;0;9;45 TSM:READY:ID=0,PAR=0,DIS=0
0;255;3;0;9;57 MCO:REG:NOT NEEDED
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.3.0
0;255;3;0;9;69 MCO:BGN:STP
0;255;3;0;9;90 MCO:BGN:INIT OK,TSP=1


Komisch ist dass nun gar keine Kommunikation mehr funktioniert (Die Node):

Code Auswählen Erweitern


__  __       ____
|  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
| |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
| |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
|_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
        |___/                      2.3.0

51 MCO:BGN:INIT NODE,CP=RRNNA---,VER=2.3.0
79 TSM:INIT
83 TSF:WUR:MS=0
88 TSM:INIT:TSP OK
94 TSF:SID:OK,ID=111
100 TSM:FPAR
1320 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3340 !TSM:FPAR:NO REPLY
3346 TSM:FPAR
4567 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
6586 !TSM:FPAR:NO REPLY
6592 TSM:FPAR
7813 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
9832 !TSM:FPAR:NO REPLY
9838 TSM:FPAR
11059 TSF:MSG:SEND,111-111-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
13078 !TSM:FPAR:FAIL
13082 TSM:FAIL:CNT=1
13088 TSM:FAIL:DIS
13094 TSF:TDI:TSL


Wahrscheinlich hat das keinen Zusammenhang mit deinen Änderungen und meine Tests bisher wären wertlos.
Das könnte doch ein HW Problem sein welches ich genauer ansehen muss. Aber leider muss ich nun erst mal weg.

[Ranseyer]

Ahh, Lustig:
-Nur beim Node die RFM69HW Option weggenommen und die kommunizieren wieder !
-Wenn ich das auch beim GW wegnehme ändert sich nix.

=> Sensor liefert fleissig Daten , aber es kommen keine "Kommandos" auf der Debug-Konsole des Nodes an.
Was ich nicht verstehe: Die Kommunikation muss doch bereits beidseitig funktionieren oder hab ich nen Denkfehler ?

[Wallmeier]

Ich teste auch gerne mit. Ist geplant irgendwann eine OTA Funktion über fhem einzubauen?

Hatte ich vor längerer Zeit mal als Patch zur Verfügung gestellt - wurde aber nie übernommen...

Zu finden unter https://forum.fhem.de/index.php/topic,81917.msg744431.html#msg744431 ...

[PeMue]

... ich klinke mich dann auch mal ein, das mit dem OTA würde mich auch brennend interessieren. Aber m.Wn. ist der Quellcode des Bootloaders noch nicht öffentlich.

Gruß PeMue

[dirkcx]

... ich klinke mich dann auch mal ein, das mit dem OTA würde mich auch brennend interessieren. Aber m.Wn. ist der Quellcode des Bootloaders noch nicht öffentlich.

Gruß PeMue

Ich verwende den Bootloader hier und habe damit keine Probleme.
https://github.com/mysensors/MySensorsBootloaderRF24
Upload erfolgt über https://www.mysensors.org/controller/myscontroller, bin aber Mac/Linux User, daher ist diese Windows-Anwendung für mich nur suboptimal.

[dirkcx]

Hatte ich vor längerer Zeit mal als Patch zur Verfügung gestellt - wurde aber nie übernommen...

Zu finden unter https://forum.fhem.de/index.php/topic,81917.msg744431.html#msg744431 ...

Ich weiß nicht, wie ich den Patch mit dem Code zusammenführen muss und per Hand scheint mir das sehr aufwändig. Und ich habe keine Ahnung von Perl
Ich würde aber gerne beim Test unterstützen, wenn ich die Originaldatei bekommen würde

[Beta-User]

Yup, OTA-code ist public...

Wäre also für jemanden mit guten C/C++-Kenntissen sicher keine große Übung, den für RS485@Serial umzubauen .

Was den OTA-Patch angeht (habs nur kurz überflogen):
-- Die Constants.pm dürfte jetzt bereits den Stand haben
-- Die Änderung in der "Device" ist ja überraschend minimalistisch, ich bau's demnächst ein.

Dann kommt vermutlich wegen des Dialogfeld-Themas der heartbeat-Request in die sets statt der gets rein, dann ggf. gleich mit der Option, das wahlweise mit und ohne Response-Event "zu befehlen". Hat sonst jemand die heartbeat-Probleme wie Ranseyer?

Zur Erläuterung: Bei meinen Vorversuchen hatte ich auch die anderen beiden Dateien (+die 00_MYSENSORS.pm und die Message.pm) mal abgeändert, war aber der Überzeugung, das aber dann wieder ausgebaut zu haben.

Interessieren würde mich im Moment noch: Kennt jemand eine Möglichkeit, den "Transportweg" abzufragen? Das RSSI-Thema macht nur bei RFM Sinn, OTA im Moment nur bei nRF24 => beim Rest gleich ignorieren wäre das Ziel (solange keiner einen Bootloader für RS485 baut ). Zu nRF24-OTA noch: Da der Kanal 76 da zwingend ist, aber nicht jeder diesen nutzt (ich z.B. nicht), müßte man eigentlich mit/nach dem Request an die Node für eine gewisse Zeit den Kanal umschalten. Kennt einer einen Weg dafür (flashen war nicht gemeint, Perl... )?

[Wallmeier]

OTA macht auch beim RFM69 Sinn - nur damit habe ich es getestet...

[Beta-User]

OK, Danke für die Info - interessant wäre es trotzdem, wie man es einsetzt ist ja was anderes .
Im ersten Post sind jetzt die OTA-Dinge eingearbeitet, ich hoffe, ohne größere Kollateralschäden. Aber Vorsicht: das war doch eine größere Aktion als auf dem ersten Blick gedacht, die Strukturen sind teilweise etwas auseinander gedriftet gewesen, so dass ich einiges leicht ummodeln mußte.
Im Moment kann ich nur behaupten, dass mein FHEM mit diesen Dateien startet, die Sensoren Werte liefern und ich testweise auch Nodes einen heartbeat abverlangen kann.
Vielleicht kann jemand den OTA-Teil Testen, der passende Nodes hat, ich müßte erst noch eine Node vorbereiten? Die Änderungen in der Constants.pm sind recht gering, ebenso in der 00_MYSENSORS, sollte also auch mit der bisherigen Device-pm zusammenarbeiten. Wenn keine größeren Probleme gemeldet werden, würde ich Hauswart bitten, diese beiden zeitnah wieder in das SVN einzuchecken?
Und @Wallmeier: Da du funktionierende RFM-Nodes hast, würde mich schon interessieren, ob RSSI-Werte kommen und ob die Richtung korrekt geraten wurde...
Und ein riesiges Dankeschön für den Patch! Super Arbeit!

[Ranseyer]

Und @Wallmeier: Da du funktionierende RFM-Nodes hast, würde mich schon interessieren, ob RSSI-Werte kommen und ob die Richtung korrekt geraten wurde...

Das würde mich auch spannend interessieren, ansonsten muss ich Ende nächster Woche mal in Richtung der HW forschen. (Hab ich Stamps gekauf mit falscher Aufschrift: "HW", oder fehlt bei der Node die IRQ Leitung, usw.)