Vorarbeiten: Update auf MySensors 2.0-API

Begonnen von Beta-User, 22 Juni 2018, 20:28:35

Vorheriges Thema - Nächstes Thema

Sidey

Hi,

mein mysensors Gateway verliert leider ab und an mal die Netzwerk Verbindung.
Da im mysensors Modul kein Reconnect eingebaut war, habe ich das mal mittels Timer nachgerüstet.

Den Patch anbei.

PS: Habe das Modul nun seit 2 Wochen mit dem Patch laufen und konnte nichts negatives feststellen.

In dem Patch sind jetzt halt aber auch die anderen Änderungen mit enthalten die nicht von mir stammen.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Hi Sidey,

Danke für den Patch, war einige Zeit weg, deswegen die späte Rückmeldung.

Ich hatte es mir gestern kurz angesehen und Hauswart auch empfohlen, das (zusammen mit der constants.pm aus dem ersten Beitrag dieses Threads) einzuchecken.

Gestern bin ich dann aber noch über diese Sache hier gestolpert: https://forum.fhem.de/index.php/topic,90682.msg831620.html#msg831620

Da du zwei Timer nutzt: Ich bin mir nicht so ganz sicher, ob sich die beide nicht irgendwie ins Gehege kommen (also der eine den anderen überschreibt).
Sollte man die beiden nicht so wie im Beispiel von Rudi aufgeführt umschreiben? (Dasselbe würde ich dann im -DEVICE auch machen, aber die werden bereits getrennt benamst).

Und: müßte man den Timer nicht beim Löschen eines GW ebenfalls ausdrücklich löschen, oder erfolgt das automatisch, weil mit dem Geräte-Hash verknüpft (bei meinem muß das ausdrücklich gemacht werden, die haben keinen Bezug zum Gerätehash)?

Sorry für die evtl. doofen Fragen, ich bin nach wie vor eigentlich kein Programmierer ::) .

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

Beim undef hast Du recht. Da müsste noch ein removeinternaltimer rein.

Ob sich die Timer ins Gehege kommen, weiss ich aktuell nicht.
Da muss ich noch drüber nachdenken.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

#93
Moin,

beim undef war/ist alles ok, da ist schon immer ein removeinternalTimer($hash) drin, das löscht alle zugehörigen timer.

Was die Struktur angeht,  noch ein paar Anmerkungen bzw. Fragen (ist eher Kosmetik):
Eigentlich ist der Funktionsname "GetConnectStatus" m.E. irreführend, es müßte eigentlich eher "DoReconnect" heißen, weil nach Ablauf dieses Timers ja effektiv "Start" aufgerufen wird (der 5-Sek.-Timer wird ja nie abgebrochen, oder?), was seinerseits "Init" ruft.

Wie wäre es,  den Heartbeat-Request und den ersten Aufruf des 5-Minuten-Timers nach "Init" zu verschieben? Das ergäbe dann m.E. eine (langsame) Dauer-Loop von "Start" und "Init", bis der angefragte Heartbeat kommt (btw. m.E. unabhängig davon, ob der Heartbeat vom GW oder eine Node dahinter kommt; das macht aber nichts, Hauptsache, die Verbindung ist (noch) da).

Btw.: Paßt der Loglevel 4 in"GetConnetStatus/DoReconnect" auf Verbindungsabbrüche?

Oder habe ich das ganze falsch interpretiert?
EDIT: Ja, falsch, es gibt den Abbruch, daher stimmt auch der Funktionsname ??? ...
Frage: Sollte man den Timer-Ablauf bei Verbindungsabbruch nicht loggen? Dann wäre im 5-Sek.-Timer nicht "Start" aufzurufen, sondern eine Zwischenfunktion, die loggt und dann "Start" aufruft. (Wieder nur Kosmetik).

Grüße, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Hauswart

Die Änderungen sind ab morgen via SVN verfügbar. Danke @Sidey und @Beta-User


@Sidey die Reconnect Probleme hatte ich vor Monaten auch mal (Workaround war at der alle 5 Minunten den Reconnect durchgeführt hatte) aber seit ein paar Monaten habe ich auch ohne at keine Probleme mehr.


Gruss
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Beta-User

Hallo zusammen,
vorab mal Danke an HAuswart und Sidey für die zwischenzeitlichen Ergänzungen.

Was 10...DEVICE angeht, muß ich zugeben, dass ich etwas den Faden verloren hatte, nachdem die OTA-Sache mit dem MyS-Bootloader wohl nicht so wollte und dann noch eine Unterbrechung wg. Urlaubs dazukam.

Heute habe ich dann mal endlich angefangen, wieder mal "echte" Hardware in die Hand zu nehmen. Hat jedenfalls bis zu dem Punkt funktioniert, dass ich einige kaputte Arduinos aussortiert habe und jetzt weiß, dass ich den Lötkolben auspacken muß bzw. das das einfachste sein wird :( .

Wenn das mit dem OTA-Thema noch länger dauern sollte, weil wieder was nicht klappt, würde ich vorschlagen, ggf. erst mal den Rest weiter zu machen und dann die OTA-Sache nochmal gesondert anzugehen.

Da es ja einige wenige gibt, die den Stand von Ende Juli (29.) runtergeladen haben (läuft auch bei mir derzeit so noch):
- Irgendwelche bekannten Probleme damit?
- OTA versucht?

Das einzige, was mir an Problemen bekannt ist: die Set-Namen müßte man in der "use-Comments"-Option ebenfalls noch automatisiert ändern (wie die Reading-Namen). Die OTA-Sache war jetzt ohne ACKs und könnte daher ggf. auch bereits jetzt schneller sein.

Oder sollte das eurer Meingung nach ggf. halt "unfertig" an den Start gehen (gefällt mir nicht so)?

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Sidey

Hi,

ich habe mich in OTA Update erst mal wieder einarbeiten müssen.
Hatte das bei einem Sensor vor über einem Jahr gemacht, aber seitdem der stabil läuft, gab es keinen Anlass etwas zu verändern :)

Jetzt habe ich zwei neue Sensoren, die den mysensorsbootloader haben. Hat ein bisschen gedauert, bis ich das hinbekommen hatte.
Ich könnte die Thematik also durchaus mal ausprobieren.

Zum Thema Heartbeat zum mysensos gateway - das scheint das reading "heartbeat" nicht zu aktualisieren, so wie es aktuell in der normalen svn Version implementiert ist.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Beta-User

Hallo Sidey,
wäre klasse, wenn du das machen könntest, ich muß eigens für OTA Hardware aufbauen und ein Gefühl dafür entwickeln.

Dann würde ich mich im Gegenzug endlich mal dran machen, den set_-Teil noch umzuarbeiten.

Was man evtl. noch machen könnte, wäre die Timer in DEVICE mit dem hash zu verknüpfen, wie das allg. üblich ist. (@all: Mithilfe ist gerne gesehen!)




Was den heartbeat am GW angeht:
Hast du mehrere GW's? Ich hatte eben die Daten bei mir mal geprüft. Da hatte das erste ein Reading "last" mit einem ziemlich aktuellen Zeitstempel, das scheint also aktualisiert zu werden, allerdings (wenn es so gemacht ist wie an den DEVICE-Devices) nichttriggernd. Man muß also den Browser-refresh ausführen, damit man Änderungen sieht.
ABER: das 2. GW, das ich mir angesehen hatte, hatte gar kein solches Reading.

Muß ich mir mal ansehen :( . (Bei der Gelegenheit: Braucht man die Angabe überhaupt noch? Ich hatte das bei meinen ersten Gehversuchen reingebaut, quasi als händische Kontrollmöglichkeit. Jetzt ist es evtl. unnötig und verwirrt ggf. mehr als es hilft.)

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Mathea

Hi Leute,

vielen Dank erst mal für die Arbeit am MySensors Modul! Mein DIY Netzwerk wächst stetig.

Allerdings stürzt seit dem Update leider FHEM ab wenn ich einzelne bereits angelernte Nodes neu starte (z.B. Stecker raus und wieder rein). Im Log findet sich anschließend folgende Fehlermeldung:

Undefined subroutine &MYSENSORS::DEVICE::onStreamMessage called at ./FHEM/00_MYSENSORS.pm line 428.

Meine Nodes laufen alle auf dem MYSbootlader und ich als Laie könnte mir vorstellen, dass es damit zusammenhängt. Während des Bootens schickt der Bootloader nämlich irgendwelche "Firmware Check" Messages. Vielleicht kann das FHEM Modul nicht richtig mit diesen umgehen.

Sobald man neue Nodes einschaltet, dessen Node-ID in fhem noch nicht definiert sind, stürzt aber komischerweise nichts ab und das Gerät wird ordnungsgemäß per autocreate hinzugefügt.

Gibt es eine Möglichkeit, dieses Problem zu beheben?

Viele Grüße,
Mathea

Hauswart

Kannst du die Message vom Node aufzeichnen, wenn es neu startet?
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Beta-User

Zitat von: Mathea am 19 September 2018, 22:00:38
Undefined subroutine &MYSENSORS::DEVICE::onStreamMessage called at ./FHEM/00_MYSENSORS.pm line 428.

Ich unterstelle mal, dass du nicht eine der aktualisierten 10_MYSENSORS_DEVICE.pm-Fassungen aus dem Thread hier verwendest, sondern die über das reguläre update verteilten?

Wenn dem so ist, füge bitte in deine -DEVICE.pm (z.B. vor der sub attr) folgendes ein:
sub onStreamMessage($$) {
    my ($hash, $msg) = @_;
}

Versuch's dann nochmal. Wenn das dann den Fehler behebt, bitte um Info.
@Hauswart: Wenn das das Problem behebt: kannst du das dann in die 10....pm einpflegen und ins svn geben?

Danke für die Fehlermeldung. Danach darfst du natürlich gerne auch die Version hier aus dem Thread austesten (am besten die von Ende Juli). Damit könnte auch OTA funktionieren...

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Hauswart

@Mathea kannst du diese Datei bitte kurz testen?
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Mathea

Zitat von: Hauswart am 20 September 2018, 07:35:26
@Mathea kannst du diese Datei bitte kurz testen?

@Hauswart, vielen Dank für den schnellen Patch und die Hilfe! Das hat das Problem behoben :) Habe drei verschiedene Nodes neu gestartet und bei keinem ist FHEM ausgefallen. Es findet sich auch keine Fehlermeldung mehr im Log.

@Beta-User: Vorher hatte ich tatsächlich das File aus dem regulären Update drin und mich noch nicht an die Versionen hier aus dem Thread getraut.

Bezüglich OTA:
Ich kenne das Unterfangen via der Windows MYScontroller-Software aus dem MySensors Forum. Ist meine Annahme korrekt, dass ich für eine Nutzung der FHEM-internen OTA Funktionalität das dort genutzte firmware-config.csv file mitsamt firmware .hex files in einen Ordner auf meinen fhem Server kopieren kann? Muss dieser Ordner an einem bestimmten Platz liegen und einen bestimmten Namen haben?
Außerdem: Wie wird das FOTA Update von batteriebetriebenen Nodes gehandhabt, die SmartSleep nutzen? Im MYScontroller hat man die Möglichkeit, ein Device als "batteriebetrieben" zu kennzeichnen. In dem Moment wartet MYScontroller mit dem Senden der Reboot Message bis eine SmartSleep Nachricht des Nodes empfangen wurde. Kann das das FHEM Modul auch?

Gruß,
Mathea

Hauswart

Zitat von: Mathea am 20 September 2018, 15:06:02
@Hauswart, vielen Dank für den schnellen Patch und die Hilfe! Das hat das Problem behoben :) Habe drei verschiedene Nodes neu gestartet und bei keinem ist FHEM ausgefallen. Es findet sich auch keine Fehlermeldung mehr im Log.

@Beta-User: Vorher hatte ich tatsächlich das File aus dem regulären Update drin und mich noch nicht an die Versionen hier aus dem Thread getraut.

Bezüglich OTA:
Ich kenne das Unterfangen via der Windows MYScontroller-Software aus dem MySensors Forum. Ist meine Annahme korrekt, dass ich für eine Nutzung der FHEM-internen OTA Funktionalität das dort genutzte firmware-config.csv file mitsamt firmware .hex files in einen Ordner auf meinen fhem Server kopieren kann? Muss dieser Ordner an einem bestimmten Platz liegen und einen bestimmten Namen haben?
Außerdem: Wie wird das FOTA Update von batteriebetriebenen Nodes gehandhabt, die SmartSleep nutzen? Im MYScontroller hat man die Möglichkeit, ein Device als "batteriebetrieben" zu kennzeichnen. In dem Moment wartet MYScontroller mit dem Senden der Reboot Message bis eine SmartSleep Nachricht des Nodes empfangen wurde. Kann das das FHEM Modul auch?

Gruß,
Mathea
Danke für die Blumen, aber @Beta-User hat die Arbeit geleistet. Ich habe es nur schnell zusammengeschustert. Werde es erst morgen hochladen können somit ab Samstag für alle.
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Beta-User

Zitat von: Hauswart am 20 September 2018, 15:16:49
Danke für die Blumen, aber @Beta-User hat die Arbeit geleistet. Ich habe es nur schnell zusammengeschustert. Werde es erst morgen hochladen können somit ab Samstag für alle.
Danke für die schnelle Reaktion deinerseits, die Reparatur an sich war Ehrensache, ich hab's schließlich auch verbockt ;) !

@Mathea:
Danke für die schnelle Rückmeldung.

Das mit dem OTA funktioniert (hoffentlich) ziemlich genau so wie von dir beschrieben, das csv ist dasselbe, die passenden Dateiorte auf dem FHEM-Rechner stehen nach meiner Erinnerung in der Commandref.

FHEM erkennt übrigens automatisch, dass es sich um smartsleep-Nodes handelt und startet das update dann erst in einer "Wachphase". Man muß halt zuerst warten, bis die Node erstmalig eine Meldung abgesetzt hat, dass sie jetzt "smart" schlafen geht (sieht man ggf. erst nach einem Browser-refresh).

Man kann jetzt übrigens auch jede andere Art von Info (nicht nur OTA) an smartsleep-Nodes senden (davon gehe ich zumindest nach meinen bisherigen Tests aus).

Es gab bei den OTA-updates allerdings noch ein Problem: es hat sehr lange gedauert, bis das durchgelaufen ist. Ob das jetzt beseitigt ist, wissen wir noch nicht. Ich habe da "auf Verdacht" was geändert, bin aber selbst noch nicht zum Testen gekommen (ich nutze eigentlich nur noch RS485-Nodes mit Hardwareserial, da geht das eh' nicht bzw. nur mit DualOptiboot).

Wenn du also testen magst: Gerne :) .

Solange du "nur die bisherige" Funktionalität nutzt, sollte das ungefährlich sein.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files