Autor Thema: Vorarbeiten: Update auf MySensors 2.0-API  (Gelesen 1461 mal)

Offline Wallmeier

  • Full Member
  • ***
  • Beiträge: 117
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #45 am: 02 Juli 2018, 22:30:14 »
fhem läuft bei mir auf einem Raspi 3B und das Update dauert ca. 3-5 Minuten...

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3398
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #46 am: 08 Juli 2018, 13:35:56 »
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:

Zitat
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
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.0-alpha@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW | SIGNALduino | MapleCUN

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3398
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #47 am: 10 Juli 2018, 21:11:48 »
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
« Letzte Änderung: 16 Juli 2018, 09:32:00 von Beta-User »
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.0-alpha@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW | SIGNALduino | MapleCUN

Offline Wallmeier

  • Full Member
  • ***
  • Beiträge: 117
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #48 am: 11 Juli 2018, 20:30:13 »
Die neue Version liefert jetzt bei mir plausible RSSI-Werte...

Danke!

Offline dirkcx

  • New Member
  • *
  • Beiträge: 33
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #49 am: 11 Juli 2018, 21:05:33 »
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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3398
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #50 am: 11 Juli 2018, 21:52:14 »
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!
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.0-alpha@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW | SIGNALduino | MapleCUN

Offline Wallmeier

  • Full Member
  • ***
  • Beiträge: 117
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #51 am: 11 Juli 2018, 21:59:36 »
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 :)

Offline dirkcx

  • New Member
  • *
  • Beiträge: 33
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #52 am: 12 Juli 2018, 22:17:06 »
Bei meinem Node wird folgendes angezeigt (nRF24l01+) mit
#define MY_SIGNAL_REPORT_ENABLED
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

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3398
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #53 am: 13 Juli 2018, 12:02:17 »
...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?
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.0-alpha@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW | SIGNALduino | MapleCUN

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3398
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #54 am: 14 Juli 2018, 05:21:32 »
Zum Testen für das zeitversetzte Senden erste funktionierende Fassung anbei 8) :) ;D 8) .

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
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.0-alpha@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW | SIGNALduino | MapleCUN

Offline dirkcx

  • New Member
  • *
  • Beiträge: 33
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #55 am: 15 Juli 2018, 04:51:33 »
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.

Offline Beta-User

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 3398
Antw:Vorarbeiten: Update auf MySensors 2.0-API
« Antwort #56 am: 16 Juli 2018, 09:50:25 »
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.
Server: HP-T5740 mit Debian stretch (i386) + aktuellem FHEM | ConfigDB | VCCU mit einiger HM-Hardware | MySensors seriell (2.3.0-alpha@RS485, div. konkrete Hardware, u.a. einige DS18B20) | Milight@ESP-GW | SIGNALduino | MapleCUN