Eigene ESP8266 Raumsensoren

[justme1968]

@Shojo: stimmt da war noch etwas. diese diskussion hatten wir schon mal.wir müssen für die INIT nachricht eigentlich noch das device mit angeben.  da das ganze vom der usb version kommt schaut das KeyValue modul auch im io nach. die usb und die tcp version kann zwar auch mehrere sensoren pro verbindung haben, diese hängen aber normalerweise logisch zusammen so das ein einziges dictionary reicht. bei der udp version kommen aber komplett unterschiedliche sensoren über das gleiche io und jeder sensor braucht ein eigenes dictionary. da müssen wir vermutlich auch noch mal nachbessern.

mal sehen ob HCS den thread findet. ich mach ihn mal drauf aufmerksam.


die oben angesprochenen ergänzungen müssten dann auch im KVUDP modul ergänzt werden.


@habeIchVergessen: das proíbem mit dem rückwärts abfragen der config ist das sensor und fhem seite nicht mehr so schön entkoppelt sind. wenn der sensor einfach ein mal die DICTIONARY nachricht schickt ist die trennung viel sauberer.

[habeIchVergessen]

Kann man machen. Sehe aber keinen großen Mehrwert.
Die Entkopplung ist immer noch gegeben, da die FHEM-Seite ja aktiv werden muss. Dafür wird eine IP benötigt, die aus der initialen Multicast-Nachricht extrahiert wird.

Aktuell kann nur die Chip-ID benutzt werden, um Software-/Netzwerkänderungen detektieren zu können.
Dies würde ich schon der "schlauen Seite" (FHEM) überlassen.

[HCS]

ich mach ihn mal drauf aufmerksam.

Die Herrschaften haben geläutet? 

Da es mir an Zeit mangelt, weil ich eh schon zu viele Projekte laufen habe und es irgendwie keinen großen Sinn macht, mich in etwas, das ich nicht habe und nicht brauche, reinzukämpfen, wäre es vermutlich am einfachsten, wenn jemand einen Patch erstellt.

[justme1968]

ich schau es mir ab sobald mein sensor für den öltank in betrieb geht.

[Shojo]

Ich muss mal schauen  wie ich Zeit finde, werde mich sonst mal in Perl einlesen...
Kann ja nun auch nicht schwerer als C# / C++ / Java sein...

[justme1968]

eigentlich muss man nur:
- sich das nachrichtenformat ausdenken so das es rückwärts kompatibel ist.
  die sensor id muss halt mit in die nachricht

- die regex im code zum erkennen der nachricht erweitern

- die INIT nachricht noch in die device internals stecken, nicht nur in die internals des IO

[habeIchVergessen]

bei der udp version kommen aber komplett unterschiedliche sensoren über das gleiche io und jeder sensor braucht ein eigenes dictionary. da müssen wir vermutlich auch noch mal nachbessern.

das hat HCS schon im KeyValueProtocol eingebaut.
Wenn das Attribut Mapping keine Daten enthält, dann wird versucht, das Internal <IODev>_Mapping zu lesen. Dies wird durch KVPUDP gesetzt.
Leider funktioniert dies nicht bei der ersten Nachricht und AutoCreate, da die Internals erst nach den Attributen geschrieben werden.

[justme1968]

ja. das hatten wir vorgesehen. das reicht aber für den udp fall noch nicht. da ein KVUDP device ja nachrichten von mehreren unterschiedlichen sensoren empfangen kann und diese auch unterschiedliche mappings haben kann. im usb und tcp fall gibt es pro IO nur nachrichten von einem sketch mit einem mapping.

die eigentlich saubere version wäre wenn es im udp fall eine dreistufige architektur gäbe. 1 KVUDP mit N devices mit M sensoren. das ist aber übertrieben.

deshalb die idee das KVUDP die INIT nachricht nicht ins IODev (also sich selber schreibt) sondern ans KVP device weiter gibt und diese dort in den internals abgelegt werden und dieses dann zuerst in den eigenen internals schaut und erst danach im IO.

das mit dem autocreate ist auch kein problem. man kann die nachricht die das autocreate triggers beim autocreate mit übergeben und beim anlegen des device mit verarbeiten. dann geht auch die erste nachricht nicht verloren.

[habeIchVergessen]

KVPUDP übermittelt via addvals die IP und das Dictionary an jedes KeyValueProtocol-Device, für das Daten empfangen werden.
Sofern diese vorher per /config... gelesen wurden.

[justme1968]

ja. aber ich mag diesen config rückweg nicht . INIT nachrichten die der sensor richtung fhem schickt sind besser entkoppelt.

[habeIchVergessen]

dann geht auch die erste nachricht nicht verloren.

die erste Nachricht geht nicht verloren! die Readings sind einfach nicht gemappt und stehen da mit 1=ABC, 2=DEF drin.

ja. aber ich mag diesen config rückweg nicht . INIT nachrichten die der sensor richtung fhem schickt sind besser entkoppelt.

was passiert, wenn FHEM neu startet und die Liste der bekannten NodeMCU's weg ist (IP ist noch nicht bekannt)?

[justme1968]

die erste nachricht geht beim autocreate immer verloren wenn man sie nicht extra behandelt.

die ip ist für den weg sensor -> fhem ja eigentlich nicht relevant. nach der ersten nachricht ist sie ja wieder bekannt.

mit der config abfrage ist aber der umgekehrte weg nicht abgedeckt. wenn der sensor neu startet (und vielleicht sogar eine neue ip bekommt) erfährt fhem davon nichts da config nur bei der ersten nachricht abgefragt. wenn der sketch nach dem starten eine init nachricht schickt kann man auf fhem seite darauf reagieren falls das neu starten nicht beabsichtig war.

[habeIchVergessen]

dafür gibt es die Nachricht "REFRESH CONFIG REQUEST"
wenn der Sketch diese bei jedem WiFi-Connect sendet, dann ruft KVPUDP /config auf und aktualisiert die internen Caches.
Bei der Nachrichtenverarbeitung wird dann aus dem Cache an die Devices weitergereicht.

[justme1968]

aber warum der config umweg? der sketch  kann doch einfach direkt die relevanten daten senden.

[habeIchVergessen]

wenn FHEM erstmalig von einem NodeMCU Daten empfängt, dann müssen die INIT-Daten ebenfalls transportiert werden.
Dafür gibt es das HTTP-GET auf /config.