MySensors - commandref Korrekturen und Ergänzungen

Begonnen von ph1959de, 25 März 2016, 12:27:40

Vorheriges Thema - Nächstes Thema

ph1959de

Ich habe begonnen, mich mit dem Thema MySensors zu beschäftigen (plane, demnächst einige Dinge einzusetzen). Hab dann für mich erst mal "die Fäden sortiert" ... Resultat sind die Wiki-Seiten über MySensors (natürlich noch korrektur- und ausbaufähig).

In der commandref sind mir bei der Gelegenheit ein paar Fehler aufgefallen:

Generell:

  • ich würde vorschlagen, sofern es nicht um die Modulnamen geht, MySensors immer so (MySensors) zu schreiben; das würde es eindeutiger machen.
  • acknowledge -> acknowledgement


MYSENSORS:

  • att <name> ...  -> attr <name> ...
  • ist "autocreate" immer noch ein separates Attribut am MySensors Gateway oder geht da jetzt (auch?) das globale autocreate? Außerdem würde ich für den Text eine Änderung auf enables auto-creation of MySensors Nodes (MYSENSOR_DEVICE) on receipt of presentation-messages

MYSENSORS_DEVICE:

  • att <name> requestAck  -> attr <name> requestAck
  • fehlt: attr <name> IODev <gateway>
  • requires a MYSENSOR-device as IODev -> der Link aufs Gateway Device ist falsch (das letzte S fehlt)
  • Als generelle "Einleitung" (Vorschlag, vielleicht ist mein Verständnis aber auch falsch): represents a Sensor Node, a Repeater-Sensor Node, or a single sensor attached to a Sensor Node; all of them may in the following be referred to as "Node"

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Beta-User

#1
Hallo Peter,

gute Idee mit dem Wiki, sowas hatte mir tendenziell bei meinen Startversuchen vor einigen Monaten gefehlt ;).

Es scheint zu Mysensors generell und v.a. auch zum Zusammenspiel mit FHEM manches zu geben, was mir als schnelle Orientierungshilfe so im Telegrammstil einfiele:


FHEM <-> MySensors
- Wie ist das mit der Vergabe der Node-ID's: (Node hat keine gespeicherte ID? -> Anfrage FHEM - (Prüfung der NRF+-ID?) -> Vergabe der ID durch FHEM (letzte +1 (bzw. anhand der bekannten NRF+-ID?))  -> Senden zum Sensor -> Abspeichern im EEPROM (überlebt dort dann auch reflashes, selbst wenn es dann ein ganz anderer Sensor-Typ ist (Hatte da nette Ahas beim Hin- und Hertauschen diverser Arduinos auf mehreren Steckbrettern; seitdem definiere ich die Node-ID lieber im einzelnen Sketch)
- Es macht nur Sinn, Typen und Variablen zu nutzen, die in der 10_MYSENSORS_DEVICE.pm auch hinterlegt sind. Achtung dort: "receives" und "sends" sind aus der Sicht der Node gemeint! Gibt es diese (noch) nicht, sollte man sie entweder vom Maintainer (ntruchses) angelegen lassen (selber geht natürlich auch...), oder man steigt auf andere Typen um (z.B. Wasser- statt Gaszähler)
- das Mapping muß passen, scheint aber (noch) nicht bei allen Sensor-Typen per autocreate vollständig zu sein
- (hat jemand Erfahrung mit OTA-Updates??? EDIT: ist hier gut beschrieben.
EDIT2: Der generelle Ablauf etc. ist gut hier erklärt: https://forum.mysensors.org/topic/1914/over-the-air-ota-bootloading-update-tutorial/9)
EDIT3:
- Gateway: Besser mit einem seriellen beginnen! Für WiFi-GW (ESP8266/NodeMCU) auf jeden Fall den dev.-Tree (2.0.0-beta) nutzen und natürlich auch den ESP-Teil in der Arduino-IDE auf den aktuellen Stand bringen!!!

EDIT:
MySensors, FHEM und MQTT
(Keine Erfahrung, aber: bei der Einbindung neuer, bislang unbekannter Sensor-Typen dürfte der "Umweg" über das MQTT-Protokoll evtl. ein gangbarer Weg sein, da (nach meinem ganz subjektiven Eindruck) die Teilstrecken FHEM<->MQTT bzw. MySensors <-> MQTT jeweils für sich schnelleren Entwicklungen unterworfen zu sein scheinen als die native FHEM-MySensors-Schnittstelle bzw. ggf. auch spezielle Sachen möglich machen könnten, die gar nicht in die native MySensors-Schnittstelle gehören. EDIT:Dann war mir lange nicht klar, dass der MQTT-Server auch ein (ESP-)Wifi-GW sein kann, nicht nur der FHEM-Rechner (oder ein weiterer); das sollte aber jemand darstellen, der praktische Erfahrungen hat....


MySensors Funk
Ich kenne noch min. zwei andere, die erst mal Probleme mit der Funk-Reichweite hatten. Wenn man nicht wirklich nur wenige Meter bzw. eine Decke/Wand überbrücken will:
- Unbedingt für das Gateway einen NRF+ mit externer Antenne nehmen (heißen PA+ oder so)! (Dann kann der Rest auch ohne auskommen bzw. es benötigen nur evtl. noch weiter entfernte, wichtige Sensoren einen PA+) EDIT: Das erscheint mir besser als die Wahl des WiFi-GW, wenn es nur um die Überbrückung von Funkstrecken zum FHEM-Rechner geht.
- Kontrollieren, ob die PA_LEVEL_... richtig eingestellt sind (auch das läßt sich nicht nur in der Myconfig.h einstellen, sondern auch im Sketch der einzelnen Nodes bzw. des GW)
- (Empfehlung?) Es gibt Stecksockel, die die Power-Regulation etc. machen und wohl auch den empfholenen Kondensator gleich mit drauf; habe diese zwar da liegen, aber noch nicht getestet; ist aber auch nicht wesentlich teurer als die einzelnen Kleinteile und erleichtert ggf. die Montage in Wanddosen usw.
EDIT2: Evtl. mal abgesehen vom Stromverbrauch (?) sind die Sockel jedenfalls keine Verschlechterung und erleichtern die Montage erheblich, wenn man den entsprechenden Bauraum hat!)
- Hinweis: ein Repeater muß nicht zwingend eine eigene Node sein. Es geht jede (sinnvollerweise nicht Batterie-gespeiste Node), man muß nur einen entsprechenden Schalter setzen (gw.begin(NULL, AUTO, true) bzw. 2.0.0-beta: #define MY_REPEATER_FEATURE).
- Wer's exotisch mag, Eigenbau-Antennenverbesserung: http://www.instructables.com/id/Enhanced-NRF24L01/ (nicht getestet)
Edit: - etwas weniger exotisch, dafür evtl. auch wirkungsvoll (wer grade keine Frischhaltefolie findet, darf auch Isolierband nehmen. Die Alufolie ist aber Pflicht! http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/ (Dank an r_knipp)

MySensors allg.
- Die Einstellungen werden im EEPROM gespeichert. Zum löschen (wer unbedingt will! M.E. ist das eigentlich nur für die Node-ID ein Problem, das man aber durch manuelle Vergabe besser lösen kann) muß man den MySensor-Lösch-Sketch nehmen, der nicht "0000..." schreibt (Arduino-Standard-Lösch-Sketch), sondern "FFFF..."
- Solange der Speicher mitmacht, kann man mehrere Sensoriken recht einfach auf einen einzigen Arduino packen, wie es geht, wird unter https://forum.mysensors.org/topic/2597/combining-mysensors-examples/2 ganz gut erläutert. 

EDIT:
(- Empfehlung: der Code der Dev.-Version (2.0.0-beta) erscheint mit für den Einstieg besser zu durchschauen zu sein; für ESPs ist er m.E. Pflicht! Soweit erkennbar läuft die Dev.-Version genauso stabil wie der master-tree)

Beispiele
https://forum.mysensors.org/topic/938/multisensor-multiactuator-sketch-testboard-tested-with-fhem-controller
Infrarot-Fernbedienung aus FHEM raus iVm. remotecontrol: https://forum.fhem.de/index.php/topic,26807.msg449776.html#msg449776
mehrere Dallas-Temperatursensoren eindeutig erkennen: https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency
https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2

Zitat von: ph1959de am 25 März 2016, 12:27:40
  • Als generelle "Einleitung" (Vorschlag, vielleicht ist mein Verständnis aber auch falsch): represents a Sensor Node, a Repeater-Sensor Node, or a single sensor attached to a Sensor Node; all of them may in the following be referred to as "Node"

Wenn ich oben von Node gesprochen habe, ist das eigentlich immer gemeint als ein Arduino+NRF+-Paar, an dem dann die eigentlichen Sensoren angeschlossen werden.
Das würde ich eher so formulieren:

MYSENSORS_DEVICE

represents one unit of a microcontroller and a wireless module. The microcontroller typically is an Arduino or ESP8266, the wireless module could be either a NRF+ or a RFM69 (but only one type of these can be used within one network/GW). A Node can serve as a Gateway, Repeater-Node and/or Sensor-Node (Rem.: GW+Sensor requires 2.0.0 Version).  You may attach one or more real sensor hardware (like temperature, light, IR...), relays or other stuff (IR Emitter, 433MHz-emitter, even a display?) to the microcontroller. Then it is called a Sensor-Node. Each sensor attached to the Node needs to be assigned to a unique internal number called Child-ID. The single Child-ID will be presented as a reading of the MYSENSORS_DEVICE within FHEM. It will only show up when the node sends a respective reading to the Gateway (refreshing the webpage may be required).

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

#2
Eine Sache wäre evtl. noch interessant (FHEM->Sensor-Node):
Wie kann man Parameter von FHEM an einzelne Nodes geben, also z.B. eine Helligkeitsschwelle oder Einschaltdauer, wenn man einen Bewegungsmelder nachbauen wollte, oder Textinfos für ein Display?

Die Übergabe von Parametern ist selten vorgesehen (z.B. beim Wasserzähler, IR-Sensor, Relays), also z.B. nicht  bei einer Bewegungsmelder-Node und in der Regel auf das Notwendige beschränkt.

Hab's (noch) nicht ausprobiert, aber es sollte eigentlich gehen, wenn man ein oder mehrere "S_CUSTOM"-Child-ID's anlegt. Dann lassen sich jeweils bis zu 5 Parameter an die Node senden. Auseinandersortieren lassen müsste es sich, wenn man neben dem Message-Typ dann noch nach der Child-ID unterscheidet; Beispiele wie das geht, müßte es bei den Mehrfachrelais geben.

EDIT: Es ist kein großes Problem, Infos oder Konfigurationsdaten an eine Node zu senden. Es muss nur in FHEM das reading gemapped sein, was am einfachsten geht, wenn man ein (oder mehrere) S_CUSTOM Childs definiert. Zum Auswerten muß man der Node natürlich sagen, wie sie mit den erhaltenen Messages umgehen soll bzw. als welchen Typ (z.B. getInt() getLong() getString()) das zu interpretieren ist.
Gutes Beispiel: https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2
Die Werte werden aber tatsächlich nur aktualisiert, wenn die Node nicht schläft, sonst dauert es bis zum nächsten Reboot (natürlich nur, wenn die Werte in der Initialisierung auch vom Controller erfragt werden).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors