Integration von MySensors in FHEM geplant?

[Peter_64]

zu
Kannst Du das etwas näher beschreiben? Es ist das nach meiner erste Mal, dass jemand grundsätzliche Kritik an den Modulen äußert. Jedenfalls bei mir waren die beiden betreffenden *.pm's über Monate problemlos im Einsatz (ich habe aber auch nicht intensiv nach Fehlern gesucht!).

Das sollte wirklich keine Kritik für das sehr gute Modul sein Ich hatte damals Relais geschalten, die gingen eine Zeit lang sehr gut, und dann aus dem nichts Probleme. Für mich als reiner Anwender nicht erklärlich. Bei Sensoren hatte ich keine Probleme. Aber wenn Zeit ist werde ich mich wieder ran tasten...

Danke für Eure Arbeit    

[Beta-User]

@ all:
Nochmal Danke, ich hätte aber vielleicht noch ausdrücklich klarstellen sollen, dass mich die Art des jeweiligen GW zu den ganzen Infos auch interessiert (ist aber bei den meisten jetzt klar.
Für Neue: "Standardstatus", GW-Art, MySensors-Version, IDE-Version (bzw. andere IDE)

btw. habe ich mal mit den Channels ein bisschen gespielt und interessanter weise,
bekomme ich bei mir auf Channel 0 und 1 keinerlei Verbindung.
Würde jetzt gerne noch das signing mit rein nehmen, aber das hab ich noch nicht so ganz geschnallt 

1. Mit der Channel-Nummer nimmt die Reichweite eher ab. >76 (Standard) soll besser sein, aber rechtliche Obergrenze in D (83?) beachten!
Vermutlich hast Du aber schlicht eine Überlagerung mit einer WLAN-Frequenz eines Routers in der Nähe und solltest einen gewissen Abstand einhalten .
2. Signing kenne ich bislang nicht; einige spezielle ESP-Module haben einen entsprechenden Chip bereits verbaut, das muß man im Sketch aktivieren; ansonsten in Software (wobei es eine der an der Kommunikation beteiligten Nodes ausdrücklich fordern muß und ein Mischbetrieb SW/HW funktionieren soll).
Jedenfalls früher gab es da bei Mysensors.org eine sehr anschauliche Darstellung dieser Geschichte und der Frage, was es an Sicherheitsgewinn bringt (ok, ist Ansichtssache, aber aus meiner Perspektive). Das ist übrigens auch sehr anschaulich, das Angriffsszenarios wie man-in-the-middle-Attacken usw. angeht => nicht nur für MySensors interessant, um die Prinzipien zu verstehen.
Hier der aktuelle Link, ist wohl im wesentlichen noch so

[kleinerDrache]

@Beta-User
ESP-WLAN Gateway

habs gerade nochmal getestet:
Reading connection: hat bei mir IMMER den Wert "startup complete" selbst wenn ich den GW komplett abschalte
Reading state: bei anlegen der Devices kommt "initialized" und dann nur noch entweder "opened" oder "disconnected" (sorry den Wert"connected" gibet garnicht)

weitere Readings hat das GW nicht.

Ich habe dann noch per StateFormat den state auf in den Device verlegt weil da sonst das Reading connection angezeigt wird (ziemlich nutzlos da es sich nie ändert)

@Feuerpfeil
Habe bei mir auch den Channel vom NRF geändert (auf 0) und erziele damit weit bessere Verbindung(weniger Abbrüche höhere Reichweite) als mit dem Standard (hab aber auch hier ca 10 WLAN Netze die mir da reinhämmern). Hast du bei dir nur am GW den Channel geändert oder auch in den Nodes ? Kondensator direkt am NRF wegen Spannung stützen ?

Wegen signing kann ich nur sagen: soft signing ist mist, sorgt für ziemlich heftige Verzögerungen, von FHEM meinem RGB Node gesagt bitte Rot bis das da ankommt dauert es schon mal 2-3 Sekunden.
Hardware hab ich mangels Masse (hab keinen Chip) nicht ausprobiert.

[Feuerpfeil]

@Feuerpfeil
Habe bei mir auch den Channel vom NRF geändert (auf 0) und erziele damit weit bessere Verbindung(weniger Abbrüche höhere Reichweite) als mit dem Standard (hab aber auch hier ca 10 WLAN Netze die mir da reinhämmern). Hast du bei dir nur am GW den Channel geändert oder auch in den Nodes ? Kondensator direkt am NRF wegen Spannung stützen ?

Wegen signing kann ich nur sagen: soft signing ist mist, sorgt für ziemlich heftige Verzögerungen, von FHEM meinem RGB Node gesagt bitte Rot bis das da ankommt dauert es schon mal 2-3 Sekunden.
Hardware hab ich mangels Masse (hab keinen Chip) nicht ausprobiert.

Die Lage mit den WLan Netzen sieht bei mir leider nicht anders aus. Aktuell sind es neun.
Werde im Januar umziehen. Bin gespannt wie es dann dort sein wird.
Ich hatte den Channel auf dem Gateway und auf dem node geändert.
Bin jetzt auf Channel 83 (RF24 channel 84). Das funktioniert so weit und so bin ich dann auch zumindest vom "Standard" Channel runter.
Am Gateway hab ich einen 10uf Kondensator drauf. Da ich als Node im Moment leider nur 5V Arduinos habe, habe ich am nrf24l01 einen fertigen Adapter vom Ali
https://www.aliexpress.com/item/New-Socket-Adapter-plate-Board-for-8Pin-NRF24L01-Wireless-Transceive-module-51/32652342305.html

Hab das mit dem signing jetzt auch so weit verstanden. 
Bei dem umfangreichen Artikel, habe ich das Wesentlich einfach übersehen.
Danke jedenfalls für den Tipp. Dann werde ich softsigning gar nicht erst ausprobieren.
Wenn meine 3V Arduinos da sind und zwei /drei nodes stabil laufen, werde ich mal welche von den ATSHAs bestellen und testen.

OTA würde mich dann ebenfalls interessieren, aber wie ich das gelesen habe, scheint die Beschaffung der Chips nicht ganz so einfach zu sein.

[kleinerDrache]

Ich verwende hier Nanos , und nehme nur für power 3,3 V. Die Daten Pins des NRF sind 5V tolerant (hier ist mir in 1 Jahr noch kein NRF abgeraucht). Chip ?? Für OTA ?? Nimm doch den MYSBootloader der braucht keinen extra Chip. Einziger unterschied mittlerweile zum anderen OTA-Bootloader : wärend des Updates kommen keine Messwerte und wenn die neue Firmware fehlerhaft ist musste unter Umständen manuell flashen weil der Sensor nicht mehr reagiert.

Die ATSHA würde ich auch nur verwenden wenn es um kritische Übertragungen geht (Türöffner, Fenster kontakte usw.) Mischbetrieb ist da problemlos möglich. Oder du nimmst halt den Sensbender da ist sowohl ein ATSHA als auch extra Speicher drauf.

[PeMue]

Hm hatte damit auch schon mal Probleme ein ändern der Sende Channels hat
1. Die reichweite gewaltig erhöht und
2. die abbrüche waren auch passe

Standardmässig läuft MySensors auf Channel 76 also 2476 Mhz. Da kommt mann schonmal mit älteren Wlan Geräten in Konflikt.

Ich gehe mal davon aus, dass man eine Kanaländerung für alle Geräte (Gateway und Sensoren) machen muss, oder? Insofern wäre da OTA recht geschickt 

Habe gerade festgestellt, dass bei mir WLAN Kanal 11 durch die Nachbarn stark belegt ist, insofern ist NRF Kanal 76 vielleicht suboptimal 

Gruß PeMue

[kleinerDrache]

Stimmt aber Obacht im Momment funkt nach Änderung des Channels OTA "NICHT" warte da immer noch auf ne Meldung von dem Bootlader Bauer

[Beta-User]

Hallo zusammen,

Anmerkungen zu den diversen Dingen:

@PeMue
Das mit dem battery level als Voltage ist evtl. einfach zu lösen:
Versuch mal, das Mapping manuell zu machen wie im nachstehenden Beispiel für IR_Send; dabei müßte es voltagex heißen mit x=ChildID, unter der Du die battery-Voltage verschickst.

Code Auswählen Erweitern

attr MYSENSOR_99 mapReading_ir_send3 3 ir_send)
Anm.: (wenn "0", dann würde das wohl mapReading_ir_send 0 ir_send lauten).
An sich ist die Lage etwas anders als der Standardfall, weil battery ein internes Reading ist, das seitens MYSENSORS_DEVICE.pm speziell behandelt wird und Voltage "eigentlich" zum Sensor-Typ Multimeter gehört (damit wäre die Alternative, ein weiteres Child vom Typ Multimeter zu präsentieren und darunter die Voltage zu versenden; das wäre m.E. aber die unsauberere). Die Unsicherheit, ob das überhaupt funktioniert kommt übrigens daher, dass seitens MySensors nicht vorgesehen ist, battery als Voltage-Wert darzustellen (jedenfalls lt. Serial API) .

Stimmt aber Obacht im Momment funkt nach Änderung des Channels OTA "NICHT" warte da immer noch auf ne Meldung von dem Bootlader Bauer

Zur Erläuterung: in dem betr. Forumsbeitrag bei Mysensors ist davon die Rede, dass in dem Bootloader-code der Channel für Updates fest auf 76 eingestellt ist. Das macht m.E. mit gewissen Einschränkungen sogar Sinn, da man so die Nodes erreicht, selbst wenn man den für die FW urspünglich mal verwendeten Channel vergessen haben sollte, aber noch ein GW mit dem richtigen Channel hat .

[Test- und Spekulationsmodus]
Folgendes Setup könnte evtl. aber gehen und uns sogar für die OTA-Funktionalität aus FHEM heraus weiterbringen:
1. GW auf Channel 76 an dem Rechner, von dem aus das Update (=*.hex?) effektiv übertragen werden soll
2. GW mit dem aktuellen Channel der Node zum Start des OTA-Vorgangs
3. GW, das auf dem "neuen" Channel läuft (braucht man nur für den Fall, dass das ein anderer ist als im 2. GW bzw. Channel 76)

Dann wäre interessant,
- wie lange die Node im OTA-Boot-Modus verbleibt und
- was der Befehl für "boot to OTA-Bootloader" wäre. Da die Nodes nach einem "Reboot-Befehl" seitens FHEM nicht mehr zu erreichen sind, könnte es sogar sein, dass das die Initiierung des OTA-Modus von FHEM aus gestartet werden könnte (bzw. schon wird).

Wäre der Status "erwarte update" "ewig" (bis zu einem Neustart aus anderen Gründen), könnte man dann mit dem 2. Rechner/GW den eigentlichen Upload-Befehl starten.

Testfelder wären:
- Klappt das mit dem Update über den MYSController, wenn dieser den OTA-Modus nicht selbst initialisiert. Er "sieht" die Node ja nicht, solange sie in einem anderen Netz (=channel) ist. Ein weiteres Absetzen des Befehls "Reboot to OTA" seitens des Tools würde vielleicht nicht schaden, kann aber evtl. nicht sauber ausgeführt werden, wenn das Tool diesen gar nicht mehr ausführen kann, wenn die Node bereits im OTA-Modus ist.
- Handelt es sich bei dem OTA-update nur um eine Art seriellen Kopierbefehls, könnte man das update evtl. auch (ähnlich der HM-updates?) mit einem Konsolenbefehl ohne das Windoof-Tool durchführen, man müßte nur das richtige Device (channel76) als I/O auswählen und natürlich die Node benennen, an die es (das Update) gehen soll.
[/Test- und Spekulationsmodus]

Sollten wir die OTA betreffenden Fragen eigentlich in den Howto-Thread auslagern? Ist sehr speziell (wobei es bei diesem Thread hier eingentlich auch nicht mehr drauf ankommt )

[kleinerDrache]

zu OTA: wenn ich das richtig verstehe geht jeder Node nach dem Reboot erstmal in Update Bereitschaft ,das sieht man schön im MYScontroller der immer 4 Meldungen betreff Firmware bekommt.
Wird in der Zeit mit einer neuen Firmware geantwortet startet die Übertragung derselben und nach Erfolg und Abgleich der CRC wird Resetet. dann beginnt das Spiel von vorne bis Firmware Node = Firmware die der Gateway anbietet. Ergo die Nodes Initialisieren das Update NICHT der GATEWAY der schickt nur den Resetbefehl.

Da aber der NRF immer nur einen Channel zur selben Zeit benutzen kann funkt das OTA mit geändertem Channel nicht mehr weil der NRF Channel im Bootloader Hardcodiert ist und das ist 76. Hast du jetzt deinen Gateway auf z.B. 0 geändert kann der MYScontroller nicht mehr auf die Anfragen vom Node reagieren weil halt falscher Channel.

zu Battery Voltage: Schau in den Sketch von mir zum Bewegungsmelder der überträgt sowohl Prozent als auch Voltage (wenn der Spannungsteiler stimmt sogar richtig). Mit dem Internen Voltage Meter von Atmega sollte auch gehen aber hab ich nicht probiert. Auch das Mapping sollte automatisch gehen. In den Attributen zwar wild durcheinander aber in den Readings tauchen nur Werte auf wo auch was drin ist. Eventuell müssen da noch die geänderten MySensors Dateien in FHEM kopiert werden da ich nicht weiß ob das schon automatisch per update passiert.

[Beta-User]

Hallo kleinerDrache,

ich verstehe Deinen Post nicht so recht. Hast Du jetzt ein oder 2 GW's im Einsatz? Dass es mit nur einem nicht gehen kann, ist klar. Man braucht das eine, um auf dem aktuellen Channel mitzuteilen, dass etwas übertagen werden soll und das andere, um die Firmware tatsächlich auf Channel 76 zu übertragen. Da die Node offensichtlich weiter funktioniert, wenn das update wg. Channel-Wechsels abgebrochen wird, ist anzunehmen, dass die FW gar nicht angefaßt wird, bevor nicht auf Channel 76 die FW-Daten rübergeschaufelt werden.
Daher die Frage vorhin:
- wie lange bleibt die Node updatebereit auf Channel 76, wenn sie in den OTA-Mode geschickt wird und
- reicht es aus, wenn man in FHEMWEB den "reboot"-Button drückt, um sie in den OTA-Mode zu versetzen?
(OK, es würde evtl. auch mit nur einem GW gehen, wenn das GW wüßte, dass es den Kanal vorübergehend auf 76 wechseln soll, sobald ein Update einer anderen Node angesagt ist; diese Funktionalität ist aber offensichtlich nicht implementiert).

Wenn Du es also bisher mit einem GW versucht hast: Hast Du ein anderes, 2. GW, das Du auf Channel 76 flashen kannst?
Wenn ich es richtig verstanden habe, hast Du einen FHEM-PI und ein Laptop mit dem MYSController.
Wenn ja: Gib doch bitte für den Laptop dieses 2. GW mit Channel 76 als GW vor. Kannst Du dann von FHEMWEB aus über das 1. GW (Channel 0) die Node in den reboot schicken und versuchen, dann das update vom Laptop aus draufbügeln oder erlaubt MYSController evtl. sogar die Verwendung von 2 I/O-s zu diesem Zweck?

Zu battery voltage: habe zwar nur kurz gesucht, bin aber nicht drauf gekommen, welchen Sketch Du meinst. Kannst Du evtl. den Link nochmal posten oder die ersten paar Zeilen Code (relevante Defines, myMessages und die presentation()); Du tätest jemandem anderen einen großen Gefallen .
Oder hast Du etwas an der MYSENSORS_DEVICE.pm geändert?

[PeMue]

Zu battery voltage: habe zwar nur kurz gesucht, bin aber nicht drauf gekommen, welchen Sketch Du meinst. Kannst Du evtl. den Link nochmal posten oder die ersten paar Zeilen Code (relevante Defines, myMessages und die presentation()); Du tätest jemandem anderen einen großen Gefallen

Das müsste der aus diesem Post sein: https://forum.fhem.de/index.php/topic,26807.msg512553.html#msg512553

[kleinerDrache]

genau der

Edit: hmpf wenn man nicht genau liest *gg*

Nein ich verwende im Moment nur einen Gateway und zwar Einen Wlan-Gateway auf ESP-Basis und update im Moment nicht OTA (Channel geändert auf 0). Ich warte auf die Sourcen Von Teek um mir selber den Bootloader zu kompilieren der dann auch auf Channel 0 lauscht.

Die Nodes müssen ja erstmal mit dem MYSBootloader bespielt werden der Reset funktioniert glaub ich auch NUR mit diesem Bootloader. MYSController läuft bei mir auf Linux unter Wine. Ich glaube es geht immer nur ein Gateway in dem Programm.

Nach dem Reset kommen 4 Meldungen im MYSController an die glaube ich auf "Inter 'configure Firmware'" lauten und nach der im MYSController hinterlegten Firmwareversion fragen. diese Sequenz dauert ca 5-10 Sekunden. Mit zwei Gateways hab ich noch nicht probiert.

Edit2: Sorry wenn ich was konfus schreibe hab hier im mom ne menge zu tun *gg* FHEM retten, MySensors weiter machen, Rechner neu machen, 3D-Drucker rumbasteln also jede menge Baustellen

[Beta-User]

@PeMue
Danke, das war er; da steht:

Code Auswählen Erweitern

present(CHILD_ID_BATT, S_MULTIMETER);
Dass es damit geht, ist klar.

und Voltage "eigentlich" zum Sensor-Typ Multimeter gehört (damit wäre die Alternative, ein weiteres Child vom Typ Multimeter zu präsentieren und darunter die Voltage zu versenden; das wäre m.E. aber die unsauberere).

Versuche es doch bitte erst mit der manuellen Vergabe des attr, sonst bekommst Du auch die anderen Multimeter-Readings per Automatik.

[Beta-User]

Edit: hmpf wenn man nicht genau liest *gg*

Kein Problem, geht uns allen hin und wieder so . Und dass ich grade auf der Suche nach diesen ganzen Feinheiten bin, macht die Sache nicht einfacher .

Ich warte auf die Sourcen Von Teek um mir selber den Bootloader zu kompilieren der dann auch auf Channel 0 lauscht.

Es gibt sourcen (auch dev.) auf Mysensors@github, ob die allerdings sooooo aktuell sind, kann ich nicht sagen (2 Monate+). M.E. ist ein entsprechend geänderter Bootloader-Channel aber nur eine halbe Lösung; wir wären alle mit einer generischen Lösung besser bedient, weil diese immer funktionieren würde (jedenfalls wenn nicht gerade der Channel 76 das funktechnische Hauptproblem ist).
Klasse wäre eine automatische GW-Umschaltung auf Channel 76 für eine bestimmte Zeit, um der Node Gelegenheit zu geben, das update abzuholen.
Wenn es "hilfsweise" mit einem 2.GW im Parallel-Betrieb ginge, wäre das auch ok.

Da Du (bis auf das 2. GW) alles bereits hast (und mir damit um einiges voraus bist): könntest Du nicht einfach den beschriebenen Test mit dem 2. GW machen ; ein serielles ist ja schnell zusammengestöpselt, wenn man die Bauteile hat . Und für das Update kannst Du ja direkt neben die "Ziel-Node" stehen, dann ist Funkreichweite auf Channel 76 vermutlich kein Störfaktor....

Danach darfst Du das auf Kanal 0 umgeflashte serielle GW gerne als Standard-GW für FHEM nutzen, ich laß Dich in Ruhe und Du kannst Dich weiter Deinen anderen Baustellen widmen .

[kleinerDrache]

klar kann ich machen wenn endlich meine Bauteile aus China da sind *gg* hab nämlich keine NRF's mehr. Müssten aber morgen oder übermorgen ankommen hoffe die sind dann dabei *lach*