Vorarbeiten: Update auf MySensors 2.0-API

[Wallmeier]

fhem läuft bei mir auf einem Raspi 3B und das Update dauert ca. 3-5 Minuten...

[Beta-User]

So,

anbei die aktualisierten Fassungen - aufgrund der Abweichungen zum Standard und einiger offener Fragen auch erst mal nur hier und nicht im ersten Post.

Was ist neu: Aus einem Kommentar wird (teilweise) ein Readingname. Der Haken an der Sache: Will man das upgedated haben, muß man erst das alte Attribut löschen . Hat man z.B. einen DS18B20 und überträgt die ID als Kommentar, wird das sauber angelegt und auch die Temp auf den Sensor unter temperature aktualisiert. Soweit also so gut. Allerdings: wenn man dann einen anderen anschließt, passiert folgendes: Da das mapping durch ist, wird der Name nicht aktualisiert. Die temp wird unter derselben ChildID gesendet. Daher kommt dann die Temp dieses Sensors auch unter der "falschen" ID an. Dass es nicht der ursprüngliche Sensor ist, erkennt man ggf. nur daran, dass das ID-Reading und der ID_Reading-Name nicht zusammenpassen (wenn man auch die ID unter ID sendet)... Ob das ein Fortschritt ist? Dürft ihr euch zu äußern .

Sieht dann so aus:

id_28FF943E36160495     28FFD6EC801402D8      2018-07-08 13:17:45

Ansonsten habe ich mir den update-Code nochmal angesehen, und fand kein Optimierungspotential (außer dass der Funktionsname flashFirmware() jedenfalls für MYSBootloader-Nodes irreführend ist). Keine Ahnung also, warum das so lange dauert.

Was nach wie vor nicht funktioniert, ist das Queuen von Nachrichten, wenn die Node bekanntermaßen schläft (der Status- und Reading-update funktioniert, es liegt also ziemlich sicher an den Funktionen zur Array-Bildung bzw. dem Senden der einzelnen Zeilen aus dem Array). Hilfe von Leuten, die wirklich Perl können, ist herzlich willkommen, dann wären wir nämlich ziemlich fertig .

Denn die anderen Dinge funktionieren "an sich", allerdings kommt bei meinen RFM69-Testnodes mit NEW-Driver kein vernünftiger Wert zurück. Das ist m.E. aber auf den Code auf der Node zurückzuführen und nichts, was am Modul geändert werden könnte. Übrigens scheinen nRF-Nodes ab 2.2 auch einen "Pseudo"-RSSI-Wert zurückzuliefern, kann sein, dass man dazu aber ein Flag setzen muß (#define MY_SIGNAL_REPORT_ENABLED). Muß mal bei Gelegenheit ein Node dafür neu flashen (meine verbliebenen nRFs sind "älter").
Vielleicht kann jemand Rückmeldung geben, der den OLD-Driver im Einsatz hat - da sollte das ootb funktionieren (nach dem, was ich dazu bisher gefunden habe).

Die "neue" MYSENSORS.pm bringt nichts wirklich neues, außer, dass die Fehlermeldung wegen eines angeblich fehlerhaften Vergleichs in L472 weg sein sollte. M.E. könnte man diese Version einchecken, ohne dass es zu Problemen für die führt, die die "offizielle" MYSENSORS_DEVICE nutzen.

Viel Spaß erst mal damit und: Rückmeldungen (und Hilfen zu dem Array-Thema) sind willkommen!

Schönen Sonntag noch,

Beta-User

[Beta-User]

Neues zum Thema RSSI:

Man muß - ähnlich wie bei den DEBUG-Anfragen - als Payload mit angeben, was man genau wissen möchte .Der Code ist daher jetzt bei beidem (auch DEBUG) so umgebaut, dass nacheinander automatisch alle in Frage kommenden Werte abgefragt werden. Kommt was sinnvolles zurück (bei RSSI-Anfragen also nicht "-256"), wird das entsprechende Reading gefüllt. Vorschläge zur Namensgebung sind willkommen.
Ich hoffe, der Automatismus kommt nicht nur mir entgegen, ich fand es jedenfalls recht umständlich, die einzelnen Get-Elemente manuell auszuwählen.

Außerdem ist die Version anbei so gestrickt, dass bei der Info einer smartSleep-Node "Ich gehe jetzt dann schlafen" das Sendefenster noch kurz (den Defaultwert von 500ms) offen gehalten wird, bevor "Asleep" gesetzt wird.

Bleibt das Thema mit der Queue...

Gruß, Beta-User

[Wallmeier]

Die neue Version liefert jetzt bei mir plausible RSSI-Werte...

Danke!

[dirkcx]

Bei mir läuft die Version mit MYSBootloader auch, wenngleich nur bei 2 von 4 Nodes der Update geklappt hat. RSSI kann der nRF24L01+ leider nicht.

[Beta-User]

Danke für die Rückmeldungen.

Was RSSI angeht: @Wallmeier: Mußtest du da was speziell einschalten im Code für die Node oder ging das so? Ich hatte erst gedacht, es ginge ohne und habe dann  nach dem ersten Mißerfolg den Code auf das #define MY_SIGNAL_REPORT_ENABLED umgestellt. Würde mich interessieren, ob das nötig ist - ich denke eigentlich nämlich nicht.

@dirkcx: Für nRF24 sollte auch ein Pseudo-Wert verfügbar sein, aber jedenfalls dafür braucht man im Code den obigen Flag. Kannst ja mal Testen. (Es wird irgend was aus den verlorenen Messages kalkuliert). Was die updates angeht, ist das echt irritierend, dass das mit dem anderen Controller so viel besser durchlaufen soll. Aber wie gesagt, ich habe keine Idee, an was es hängen könnte (unterstellt, die Positionierung des GW ist identisch) .

Meinungen zu den Reading-Namen aus dem Kommentar? Bekannte Nebenwirkungen? Sollte man das per Attribut zuschaltbar machen?

Danke jedenfalls für's Testen!

[Wallmeier]

Ich habe in meinem Sketch auf dem Node auch das define MY_SIGNAL_REPORT_ENABLED drin...

Auch die Reading-Namen aus den Kommentar funktioniert wunderbar - das möchte ich nicht mehr missen

[dirkcx]

Bei meinem Node wird folgendes angezeigt (nRF24l01+) mit

Code Auswählen Erweitern

#define MY_SIGNAL_REPORT_ENABLED

Code Auswählen Erweitern

rssi_at_IODev = 0

Reading-Namen aus den Kommentaren finde ich auch gut.

Wenn jetzt das FOTA auch mit Node mit smartSleep() immer nach dem Aufwecken funktionieren würde, wäre erstmal alles da, was ich bräuchte. Vielen Dank erstmal, @Beta-User

[Beta-User]

...mal schauen, wann ich dieses für mich dicke Perl-Brett mit dem Queuen der Messages vollend hinbekomme, heute morgen bin ich zwar einigen Problemen auf die Schliche gekommen, habe mir dabei allerdings ein paar mal FHEM abgeschossen, also solltet ihr erst mal noch etwas Geduld aufbringen .

Einwände, wenn die Debug und RSSI-Werte je ein Präfix bekommen? R_... für RSSI und XDBG_...

Was die "0" bei rRF angeht: kannst du mal mit der Node wohin gehen, wo nicht mehr alles durchkommt (ggf. am Seriellen Monitor der IDE oä mal sehen, dass Wiederholungen erforderlich werden)? Wäre interessant, ob auch dann noch die "0" kommt. Könnte nämlich sein, dass "0" schlicht heißt: alle Pakete sind ohne Wiederholung angekommen - das wäre doch auch ne Aussage, oder?

[Beta-User]

Zum Testen für das zeitversetzte Senden erste funktionierende Fassung anbei .

Muß wohl noch etwas aufräumen. Damit bekomme ich pro Durchgang eine Message durch . bei einer RFM69-Node mit eher schlechten RSSI-Werten, die sofort wieder schlafen geht.

Viel Spaß beim Testen und schönes WE!

Gruß, Beta-User

[dirkcx]

Den Präfix für RSSi usw finde ich gut. RSSI zeigt bei mir eine 1 bei einem entfernten Node, der über einen anderen Node als Repeater versorgt wird. Sonst 0.

Bei den Reading-Namen aus den Kommentaren fände ich besser wenn das per Konfig ein/aus geschaltet werden könnte. Macht doch nicht bei allem bei mir Sinn.

[Beta-User]

Hmm, dann scheint das Thema RSSI bei nRF-Nodes eher wenig Sinn zu machen, schade eigentlich.

Was die Reading-Namen angeht: Das Problem dabei ist, dass man eigentlich die Wahl bereits getroffen haben sollte, bevor die Node sich das erste Mal meldet. Das ginge zwar ggf. durch ein Attribut am GW, wäre dann aber wieder für alle Nodes an diesem GW gültig. An sich könnte man auch sagen: wer das haben will, baut Kommentare in den Code der Nodes, wer nicht, soll es eben lassen (so in die Richtung ging meine Denke, als ich das reingebaut habe).

Meine Tendenz geht zwischenzeitlich aber dahin, das so umzubauen, 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 aufecken bzw. korrigieren kann. Ist aber was, wo ich erst wieder etwas Zeit finden muß...

Bei Gelegenheit würde ich dann aber den ersten Beitrag mal anpassen und die aktuellen Versionen (ggf. vorerst ganz ohne Kommentar-basierte Readingbenennung) dort posten. Ernsthafte Probleme scheint ja bisher keiner der (wenigen) Tester der aktellen Versionen gehabt zu haben.

[Beta-User]

So,

im ersten Post des Threads finden sich jetzt nochmal aktuelle Versionen.

00_MYSENSORS.pm habe ich nur aus einem der letzten Posts nach dort verschoben, ist nur wg. L472 geändert, wer also noch eine "alte" nutzt: kein wirkliches Problem.
10_MYSENSORS_DEVICE.pm ist so umgebaut, wie im letzten Post angedacht, man muß also das comment-basierte Bennenen der Readings aktiv mit einem get anstoßen.
Allerdings funktionieren zwei Dinge noch nicht perfekt, aber da ich im Moment auch nicht so recht dazu komme, erst mal diese Zwischenversion - vielleicht kann ja jemand unterstützen:
- das Löschen der "normalen"/alten Readings klappt noch nicht innerhalb der get-Funktion (bzw. Presentation-Auswertung);
- manchmal wird eine smartSleep-Node nicht als schlafend vermerkt, wenn parallel eine der "Stapelverarbeitungsfunktionen" (RSSI oder extendedDebug) ausgeführt wird.

Alles keine essentiellen Dinge, ansonsten scheint der Code keine ernsthaften Probleme zu machen.

Wegen der Dauer des updates bei nRF: Versucht das mal mit einem GW und Repeatern mit Softwarestand 2.2.0 - es gab da bei MySensors.org einen Hinweis, dass die Probleme durch irgendwas im Framework bedingt sein könnten . Dann kann ich über dem Perl-code lange brüten...

Viel Spaß erst mal damit, freue mich über euer Feedback. Wenn die beiden Dinge vollends ausgemerzt sind, könnte das m.E. dann nach einem gewissen Testbetrieb (und nach sauberer Formatierung usw.) ins svn.

Gruß, Beta-User

[Beta-User]

Hinweise im ersten Post sind angepaßt/erweitert.

[Ranseyer]

Sorry für die evtl. dumme Frage: Ich habe ein funktionierendes RFM69 Pärchen aufgebaut und mit "New-Driver" laufen. Sollte da RSSI sinnvoll angezeigt werden ?

Code Auswählen Erweitern

Internals:
   DEF        111
   IODev      mySensGwRFM69
   I_DEBUG    1
   I_RSSI     1
   NAME       MYSENSOR_111
   NR         36
   STATE      ???
   TYPE       MYSENSORS_DEVICE
   ack        0
   getCommentReadings 1
   protocol   2.3.0
   radioId    111
   repeater   0
   READINGS:
     2018-07-20 16:07:21   SKETCH_NAME     Motion Sensor
     2018-07-20 16:07:21   SKETCH_VERSION  1.0
     2018-07-20 16:07:20   parentId        0
     2018-07-20 16:15:37   tripped1        off
   gets:
   readingMappings:
     1:
       15:
         name       armed1
       16:
         name       tripped1
   retainedMessagesForRadioId:
   sensorMappings:
     0:
       receives:
       sends:
         16
         15
     1:
       receives:
       sends:
         16
         15
     10:
       receives:
       sends:
         6
         7
     11:
       receives:
       sends:
         11
     12:
       receives:
       sends:
         12
         14
     13:
       receives:
         24
       sends:
         17
         18
         54
         55
         56
         24
     14:
       receives:
       sends:
         45
         21
         0
         2
     15:
       receives:
       sends:
         13
         43
     16:
       receives:
       sends:
         23
         37
     17:
       receives:
       sends:
     18:
       receives:
       sends:
     19:
       receives:
         36
       sends:
         36
     2:
       receives:
       sends:
         16
         15
     20:
       receives:
         32
       sends:
         33
         50
         32
     21:
       receives:
         24
       sends:
         34
         35
         24
     22:
       receives:
       sends:
         37
         43
     23:
       receives:
         24
         25
         26
         27
         28
       sends:
         24
         25
         26
         27
         28
     24:
       receives:
       sends:
         37
         43
     25:
       receives:
       sends:
         19
         20
     26:
       receives:
         40
         17
         3
       sends:
         40
         17
         3
     27:
       receives:
         41
         17
         3
       sends:
         41
         17
         3
     28:
       receives:
         40
       sends:
         40
     29:
       receives:
       sends:
         2
         0
         45
         44
         21
         46
         22
     3:
       receives:
         2
         17
       sends:
         2
         17
     30:
       receives:
       sends:
         38
         39
         14
     31:
       receives:
       sends:
         2
         16
     32:
       receives:
       sends:
         16
         15
     33:
       receives:
       sends:
         37
         16
         15
     34:
       receives:
       sends:
         37
         16
         15
     35:
       receives:
       sends:
         37
         16
         15
     36:
       receives:
         47
       sends:
         47
     37:
       receives:
       sends:
         34
         35
     38:
       receives:
       sends:
         49
     39:
       receives:
       sends:
         0
         51
         52
         53
         2
     4:
       receives:
         2
         3
         17
       sends:
         2
         3
         17
     5:
       receives:
         29
         30
         31
         3
       sends:
         29
         30
         31
         3
     6:
       receives:
       sends:
         0
         42
     7:
       receives:
       sends:
         1
     8:
       receives:
       sends:
         4
         5
     9:
       receives:
       sends:
         8
         9
         10
   sets:
     clear      noArg
     flash      noArg
     fwType     
     reboot     noArg
     time       noArg
   typeMappings:
     0:
       type       temperature
     1:
       type       humidity
     10:
       type       direction
     11:
       type       uv
     12:
       type       weight
     13:
       type       distance
     14:
       type       impedance
     15:
       type       armed
       val:
         0          off
         1          on
     16:
       type       tripped
       val:
         0          off
         1          on
     17:
       type       power
     18:
       type       energy
     19:
       type       button_on
     2:
       type       status
       val:
         0          off
         1          on
     20:
       type       button_off
     21:
       type       hvacflowstate
     22:
       type       hvacspeed
     23:
       type       brightness
       range:
         max        100
         min        0
         step       1
     24:
       type       value1
     25:
       type       value2
     26:
       type       value3
     27:
       type       value4
     28:
       type       value5
     29:
       type       up
     3:
       type       percentage
       range:
         max        100
         min        0
         step       1
     30:
       type       down
     31:
       type       stop
     32:
       type       ir_send
     33:
       type       ir_receive
     34:
       type       flow
     35:
       type       volume
     36:
       type       lockstatus
       val:
         0          off
         1          on
     37:
       type       level
     38:
       type       voltage
     39:
       type       current
     4:
       type       pressure
     40:
       type       rgb
     41:
       type       rgbw
     42:
       type       id
     43:
       type       unitprefix
     44:
       type       hvacsetpointcool
     45:
       type       hvacsetpointheat
     46:
       type       hvacflowmode
     47:
       type       text
     48:
       type       custom
     49:
       type       position
     5:
       type       forecast
       val:
         0          stable
         1          sunny
         2          cloudy
         3          unstable
         4          thunderstorm
         5          unknown
     50:
       type       ir_record
     51:
       type       ph
     52:
       type       orp
     53:
       type       ec
     54:
       type       value
     55:
       type       va
     56:
       type       power_factor
     6:
       type       rain
     7:
       type       rainrate
     8:
       type       wind
     9:
       type       gust
Attributes:
   IODev      mySensGwRFM69
   mapReading_armed1 1 armed
   mapReading_tripped1 1 tripped
   mode       node
   version    2.3.0