Eigene ESP8266 Raumsensoren

[Shojo]

Hallo,

ich habe in meinen Räumlichkeiten diverse  (Eigenbau)Raumsensoren mit einen ESP8266 Herzen.
Die Sensoren waren für meine Selbstprogrammierte HomeControl , nun möchte ich die Sensoren für FHEM wiederverwerten.

Da die Sensoren im deep sleep gehen müssen diese aktiv zu FHEM senden.
Meine Überlegung war diese:

Push zum FHEM über WebCMD:

Code Auswählen Erweitern

http://192.168.0.251:8083/fhem?cmd=setreading%20SKBB.RoomSensor_25146%20Temperature%2026.00;setreading%20SKBB.RoomSensor_25146%20Humidity%2062;setreading%20SKBB.RoomSensor_25146%20Battery%2085&XHR=1

Wenn der Sensor noch nicht angelegt ist bekomme ich ja das Result:

Code Auswählen Erweitern

Please define SKBB.RoomSensor_25146 first
Please define SKBB.RoomSensor_25146 first
Please define SKBB.RoomSensor_25146 first

Darauf würde dann der Sensor folgt reagieren:

Code Auswählen Erweitern

http://192.168.0.251:8083/fhem?cmd=define SKBB.RoomSensor_25146 dummy;define%20SKBB.RoomSensor_25146_FileLog%20FileLog%20./log/SKBB.RoomSensor_25146_FileLog_%Y.log%20SKBB.RoomSensor_25146&XHR=1

Macht das so Sinn oder mache ich hier totalen misst?

Gruß
Dennis

[Gizmo_the_great]

Ich würde das ganze über ESPeasy realisieren.
Da werden die Devices automatisch angelegt, wenn erstmal eine ESPeasy-Bridge eingerichtet ist.

Bin aber gespannt was die anderen User so empfehlen.

Grüße Gizmo


Gesendet von iPhone mit Tapatalk Pro

[MadMax-FHEM]

Hi Dennis,

warum legst du nicht den dummy, filelog etc. schon in fhem an?
Statt "als Reaktion" des Sensors?

Allerdings wirst du so wie der Aufruf aktuell lautet (in deinem Beispiel) wohl Probleme bzgl. csrfToken (FeatureLevel 5. bekommen...

Alternativen:

ESPEasy (wie bereits genannt)

Webserver auf dem ESP und dann per HTTPMOD abfragen (ist allerdings polling)

und bestimmt noch weitere Möglichkeiten...

Schon im Forum bzgl. ESP gesucht?

Gruß, Joachim

[Shojo]

Hi Joachim,
ja die "Reaktion" des Sensor  fände ich schon nett da sich so jeder selbst anlegt und ich den Code so auch einfach weitergeben kann und
csrfToken habe ich aktuell eh deaktiviert daher klappt das

HTTPMOD fällt leider raus da ich den Sensor ja im deep sleep versetzte und der dann natürlich nicht erreichbar ist.

Ja ich habe auch schon nach ESP im Forum gesucht, aber dort steh leider schon fast zu viel drinnen....
Habe dort leider noch nichts aufschlussreiches gefunden.

Werde mir dann mal ESPEasy  ansehen.

Danke euch beiden für die Vorschlage!

Gruß
Dennis 

[MadMax-FHEM]

ja die "Reaktion" des Sensor  fände ich schon nett da sich so jeder selbst anlegt und ich den Code so auch einfach weitergeben kann

Ja selbst anlegen hat was...
...aber als Reaktion wird schwer u.a. wg. dem Sleep...

csrfToken habe ich aktuell eh deaktiviert daher klappt das

Über die Risiken bist du dir im Klaren!?

HTTPMOD fällt leider raus da ich den Sensor ja im deep sleep versetzte und der dann natürlich nicht erreichbar ist.

Ja, da hast du nat. recht...

Ja ich habe auch schon nach ESP im Forum gesucht, aber dort steh leider schon fast zu viel drinnen....
Habe dort leider noch nichts aufschlussreiches gefunden.

Werde mir dann mal ESPEasy  ansehen.

Jep, ist halt auch ein wahnsinnig vielseitiges Teil...
...das ist bestimmt eine gute Wahl!

Gruß, Joachim

[Shojo]

Ja selbst anlegen hat was...
...aber als Reaktion wird schwer u.a. wg. dem Sleep...

Habe es mal eben gebaut und es läuft ^^ der Sleep wird je dann nur aktiv wenn er eingerichtet ist

Über die Risiken bist du dir im Klaren!?

Ja ich denke schon, da mein FHEM nur aus dem Lokalem Netzwerk erreichbar ist (von extern nur via VPN) sollte es vertretbar sein.
Oder liege ich da falsch?

Gruß
Dennis

[MadMax-FHEM]

Ja ich denke schon, da mein FHEM nur aus dem Lokalem Netzwerk erreichbar ist (von extern nur via VPN) sollte es vertretbar sein.
Oder liege ich da falsch?

Jep da liegst du leider total falsch!

Siehe z.B.:

https://forum.fhem.de/index.php/topic,72493.msg641206.html#msg641206

Gruß, Joachim

[supernova1963]

Hallo Dennis,

alternativ könnte man meiner Ansicht nach noch MQTT für die beschriebene Situation in Erwägung ziehen.
Die MQTT Bridge hat in fhem zwar kein autocreate, ist aber in der nativen Variante Hardware unabhängig.


Gernot

[Pf@nne]

Ich würde auch eine neue Firmware mit MQTT-Unterstützung in Erwägung ziehen.
ESPEasy oder vielleicht etwas sebstgemachtes....

https://forum.fhem.de/index.php/topic,50238.0.html
Das hier ist noch in Arbeit, wird aber nach und nach erweitert.
https://forum.fhem.de/index.php/topic,50238.0.html

https://forum.fhem.de/index.php/topic,67303.msg647791.html#msg647791

Gruß
Pf@nne

[Shojo]

Jep da liegst du leider total falsch!

Uiuiui so böse habe ich mal wieder nicht gedacht ....
Danke dir für den Hinweis, werde dann mal schnell meine Config überarbeiten!

alternativ könnte man meiner Ansicht nach noch MQTT für die beschriebene Situation in Erwägung ziehen.

Ich würde auch eine neue Firmware mit MQTT-Unterstützung in Erwägung ziehen.
ESPEasy oder vielleicht etwas sebstgemachtes...

Danke euch beiden für den Hinweis auf MQTT hatte bis jetzt mich noch nicht mit MQTT auseinandergesetzt, werde dieses aber schnell nachholen

Gruß
Dennis

[dev0]

Du kanst auch, mit eigenen Code auf dem ESP, das ESPEasy Bridge Modul verwenden. Wenn Du statt

http://192.168.0.251:8083/fhem?cmd=setreading%20SKBB.RoomSensor_25146...

einen JSON String per HTTP POST, an die vorher eingerichtete FHEM ESPEasy Bridge sendest.

Der JSON String hat folgenden Aufbau:

Code Auswählen Erweitern


{
"module": "ESPEasy",                      # darf nicht verändert werden
"version": "1.02",                        # dito.
"data": {
"ESP": {
"name": "TESTDEVICE",     # wird für autocreate benötigt
"unit": 1,                # sollte ein eideuter Werte pro ESP sein
"build": 140,             # min. 128
"sleep": 0                # 1 Wenn Sleepmode
},
"SENSOR": {
"0": {
"deviceName": "TESTDEV0",      # wird für autocreate benötigt
"valueName": "Temprature",     # Readingname
"type": 1,                     # Sensor Werte folgen
"value": "23.2"                # Reading Wert
},
"1": {
"deviceName": "TESTDEV1",
"valueName": "Humidity",
"type": 1,
"value": "0"
},
"2": {
"deviceName": "TESTDEV2",
"valueName": "Motion",
"type": 10,                       # type switch
"value": "0"                      # 0 oder 1 -> off/on in FHEM
}
}
}
}

Damit funktioniert dann auch autocreate, basic auth, access control lists, etc...

Du könntest dann auch Deinen ESP über das Modul steuern, wenn der ESP nicht im deep sleep ist und Du Dich an folgende Syntax hälst:

Code Auswählen Erweitern


http://ESP-IP:80/control?cmd=<BEFEHL>[,PARAM1][,PARAM2][,PARAMn]

Der Aufruf dafür sähe in FHEM so aus:

Code Auswählen Erweitern


set <ESP> raw BEFEHL PARAM1 PARAM2


[dev0]

Nachtrag: Wenn Dich das interessiert, dann findest Du Beispielcode dazu hier: https://github.com/ddtlabs/Dots/blob/master/fastled_http.ino#L274
Das Script verwendet für den Aufbau des JSON Strings die ArduinoJson Library: https://github.com/bblanchon/ArduinoJson , geht aber auch manuell.

Mit dem Script steuere ich eine Lampe mit 240 Leds (WS2812B, fastled Lib) über das ESPEasy Modul und lasse den Status über Lichtprogramme etc anzeigen.

[Shojo]

Oh,
das gefällt mir sehr!
Danke für den Tipp

PS:
Obwohl ich einige Programmier- und Projekt-Skills mitbringe braucht es seine Zeit sich ein Überblick im FHEM zu verschaffen.
Was halt viel kann, ist auch etwas komplexer

[justme1968]

wenn du den code unter kontrolle hast ist auf das KeyValueProtokol modul mit dem udp receiver an.

[dev0]

KeyValueProtokol

Das universellere KeyValueProtokol ist bestimmt besser geeignet, als ein proprietäres Protokoll nachzubilden.
Gibt es denn mittlerweile ein kleines bischen Doku dazu? Ich hatte damals (und auch jetzt auf die Schnelle) nichts dazu gefunden, die Daten in FHEM anzunehmen.

In der Commandref steht zwar:

A generic module to receive key-value-pairs from an IODevice like JeeLink.

Aber ehrlich gesagt, hat mir das nicht gereicht...

[justme1968]

im modul selber steht wie die gesendeten daten aussehen müssen.

sonst gibt es leider nur die drei threads die jeweils eine der drei io versionen beschreiben:
- per usb und kabel
- per socket wenn fhem die verbindung auf aufbaut
- per udp broadcast wenns er sensor von sich aus sendet

[Shojo]

Man das wird hier ja wirklich interessant!

Könnte mich jetzt nun wirklich im Ars** beißen, das ich so spät an FHEM geraten bin ...   

[dev0]

sonst gibt es leider nur die drei threads die jeweils eine der drei io versionen beschreiben:

Das KeyValueProtokol hat das Potenzial eine (weitere) universelle Schnittstelle für alle möglichen Devices, Systeme, etc. zu FHEM zu werden. Ohne aber die konkrete Einbindung zu dokumentieren ist es mMn unbrauchbar oder nur für den kleinen Kreis der "FHEM Insider" verwendbar. Einen Verweis auf drei Threads ohne Links finde ich ehrlich gesagt ziemlich dürftig. (Das ist absolut nicht böse gemeint, nur mein Empfinden, da es mir damals nicht geholfen hat)

@Shojo: Vielleicht versuchst Du einfach mal das KeyValueProtokol zu verwenden und berichtest von Deinen Erfahrungen.
Wenn es funktioniert, dann könntest Du den Maintainer vielleicht sogar unterstützen und einen Wiki Artikel beginnen?

[justme1968]

die threads raus zu suchen ist am handy etwas mühsam

eine wiki seite wäre schön. aber bis jetzt hat es jeder der es versucht hat so schnell hin bekommen das er danach scheinbar keinen bedarf mehr gesehen hat mit der doku anzufangen.

also bis es doku gibt: bitte einfach trotzdem versuchen und fragen wenn etwas unklar ist. es ist ganz wirklich super einfach. man sendet nur nachrichten mit sensor typ, sensor id, readings namen und werten. fhem kümmert sich um alle andere völlig automatisch. inklusive autocreate.

[Shojo]

Werde ich mir auf jeden Fall ansehen, wäre toll wenn du noch mal die Links nachreichen kannst

[Shojo]

Was mir sich noch nicht erschließt wie ich das autocreat anspreche / auslöse.

[justme1968]

das geht wie bei jedem anderen fhem modul komplett automatisch sobald eine nachricht von einem neuen device/sensor empfangen wird. du musst nur das device für das jeweilige io anlegen und autocreate nicht deaktiviert haben.

eine kurze erklärung gibt es hier: https://forum.fhem.de/index.php/topic,67925.msg594475.html#msg594475 bzw. im post direkt danach.

einen weiteren thread zur direkten anbindung per usb/seriell gibt es hier: https://forum.fhem.de/index.php/topic,44092.0.html

im thread zum LaCrosseGateway gibt es einen beschreibung zur anbindung per ip.

den thread zu KeyValueProtocoll und udp gibt es hier: https://forum.fhem.de/index.php?topic=45545.0

[Shojo]

Hi justme1968,

ich schnalle leider überhaupt nicht wie ich ein JeeLink UDP io anlege
Kannst Du mir da eine Starthilfe geben ?

[justme1968]

für udp brauchst du das modul aus dem letzten oben verlinkten thread.

der jeelink ist nur für usb und tcp.

[Shojo]

Achsoooo, da war ich ja voll auf dem Holzweg.
Ich dachte das kann FHEM von Haus aus

[justme1968]

das KVPUDP modul ist (noch ?) nicht eingecheckt. d.h. du musst es aus dem thread laden.

[Shojo]

Jo jetzt läuft es ... SEHR geil!
Danke dir für die Hilfe, jetzt kann ich mir meine Sensoren aufbauen

[Shojo]

So erster Sensor hat seine Daten per UDP gesendet

Code Auswählen Erweitern


2017.07.03 22:57:32 3 : myKVP: Received 147 bytes from '192.168.0.115''
2017-07-03 22:57:32 KeyValueProtocol KeyValueProtocol_SKBB.WifiWeatherStation_192513 Temperature: 15.90
2017-07-03 22:57:32 KeyValueProtocol KeyValueProtocol_SKBB.WifiWeatherStation_192513 Dewpoint: 15.74
2017-07-03 22:57:32 KeyValueProtocol KeyValueProtocol_SKBB.WifiWeatherStation_192513 Humidity: 99
2017-07-03 22:57:32 KeyValueProtocol KeyValueProtocol_SKBB.WifiWeatherStation_192513 Pressure: 1014
2017-07-03 22:57:32 KeyValueProtocol KeyValueProtocol_SKBB.WifiWeatherStation_192513 RSSI: -76
2017-07-03 22:57:32 KeyValueProtocol KeyValueProtocol_SKBB.WifiWeatherStation_192513 WifiQuality: 48
2017-07-03 22:57:32 KeyValueProtocol KeyValueProtocol_SKBB.WifiWeatherStation_192513 Version: 0.0.0.8_dev_udp

Musste aber noch etwas am Modul ändern da es nur 128 bytes angenommen hatte, und auch immer versucht hat eine Config zu laden.

[justme1968]

na wenn du auch so viele bytes für die id verbrätst

aber auch 256 oder 512 bytes pro nachricht sollten noch kein problem machen. und falls du mit der länge der reading namen nicht hin kommst kannst du über das mapping attribut oder die mapping nachricht gehen und in der daten nachricht kürzere namen verewnden die dann gemappt werden.

[Shojo]

na wenn du auch so viele bytes für die id verbrätst

Ok, da hast du natürlich recht

kannst du über das mapping attribut oder die mapping nachricht gehen und in der daten nachricht kürzere namen verewnden die dann gemappt werden.

Wie meinst du das mit der Mapping Nachricht ?
Kann ich das vom Sensor mitgeben?

Weil in dem "Orig." Modul wir immer versucht via HTTP eine Config vom Device abzurufen (Wo dann auch ein Mapping hinterlegt werden kann). Was ich jetzt aber nicht so dolle finde.

[justme1968]

der sensor kann eine mapping nachricht schicken. schau mal im KeyValueProtokoll pm file die letzten beiden beispiel zeilen.

[justme1968]

d.h. du kannst entweder in den nachrichten direkt die reading namen verwenden oder ganz kurze bezeichner und ein mal als erste nachricht eine zuordnung der abkürzungen zu den reading namen in der mapping nachricht.

oder du machst es von hand und verwendest das mapping attribut.

[justme1968]

ach ja: noch etwas...

es ist noch nirgendwo fest geschrieben aber wie wäre es für die sensor id dir mac adresse (plus optional laufender nummer) zu verwenden und für den type etwas das auf den sketch namen rückschlüssen lässt? dann könnte man auch ota updates über fhem einbauen.

für den rückweg (also das setzenden werten oder kommandos an den sketch) bin ich auch gerade am überlegen.

[Shojo]

der sensor kann eine mapping nachricht schicken. schau mal im KeyValueProtokoll pm file die letzten beiden beispiel zeilen.

Das werde ich mir heute Abend auf jeden Fall ansehen.

oder du machst es von hand und verwendest das mapping attribut.

Ne das soll schon der Sensor machen, finde ich schicker

aber wie wäre es für die sensor id dir mac adresse (plus optional laufender nummer) zu verwenden und für den type etwas das auf den sketch namen rückschlüssen lässt? dann könnte man auch ota updates über fhem einbauen.

Ja die MAC ist vorhanden, allerdings nur die letzten 3 Segmente da die ersten ja nur den Hersteller angeben.
Und der Sketchname ist auch drinnen.
SKBB.WifiWeatherStation <--Sketch  MAC-->192513 (19:25:13)

Und OTA wäre natürlich sehr geil!
Aktuell geht das übers Webif, wobei ich das über FHEM besser finden würde.

für den rückweg (also das setzenden werten oder kommandos an den sketch) bin ich auch gerade am überlegen.

Ja das wäre natürlich sehr geil. am besten mit einer Queue wenn der Sender in DeepSleep ist.

[habeIchVergessen]

in KVPUDP ist der serverseitige OTA-Anteil drin. Wird in einer ähnlichen Form auch von der TCP-Variante benutzt.
Damit die neue Firmware zum NodeMCU kommt, muss dieser per HTTP-Post die Daten entgegen nehmen.

schau mal in EspWifi.ino (NodeMCU.zip aus dem UDP-Thread)

Code Auswählen Erweitern


server.addHandler(new FunctionRequestHandler(httpHandleOTA, httpHandleOTAData, ("/ota/" + getChipID() + ".bin").c_str(), HTTP_POST));


[justme1968]

weißt du ob das kompatibel zur arduinoOta variante ist?

[habeIchVergessen]

ArduinoOTA ist über ein PULL (HTTP GET) vom NodeMCU realisiert. Es wird ein zusätzlicher WebServer benötigt.

KVPUDP macht ein PUSH (HTTP POST).

[justme1968]

ok. danke.

[Shojo]

Code Auswählen Erweitern


server.addHandler(new FunctionRequestHandler(httpHandleOTA, httpHandleOTAData, ("/ota/" + getChipID() + ".bin").c_str(), HTTP_POST));


Ja das ist auch meine Meinung nach eine gute Lösung!
Blos wie bekomme ich nun die Funktionalität in den Fhem Device ?

[habeIchVergessen]

set <KVPUDP-Name> flash

[Shojo]

Oh, ok das ist ja nicht schwer 

[Shojo]

Ok ... ich bin echt zu blöd für Perl....

Ich blick den Code nicht 36_KVPUDO.pm sowie 36_KeyValueProtocol.pm

Oder sehe ich das richtig, das ich aktuell kein Mapping über UDP machen kann das ich die Args dort nicht übergeben kann?

[justme1968]

du musst doch auf perl seite gar nichts machen.

von KVPUDO wird alles was per udp rein kommt 1:1 an KeyValueProtocol weitergereicht. alles weitere passiert dann dort.

dein sketch muss eine init nachricht schicken die z,b. so ausschaut:

Code Auswählen Erweitern

INIT DICTIONARY U=UpTime,S=SSID,T=LastReceptionDate,M=Mode,O=OTA-State

dann kann die eigentliche nachricht so aussehen:

Code Auswählen Erweitern

OK VALUES LGW 12345 U=2345678, S=MyCoolNetwork,T=2015-11-17 13:39:14,M=OK,Connected,Cool,O=Ready

statt so:

Code Auswählen Erweitern

OK VALUES LGW 12345 UpTime=2345678, SSID=MyCoolNetwork,LastReceiveTime=2015-11-17 13:39:14,2015-11-18 14:15:16, Mode=OK,Connected,Cool,OTA=Ready


du kannst dir zum testen ein JeeLink device anlegen. dort gibt es ein

Code Auswählen Erweitern

set <name> parse <nachricht>kommando mit dem du nachrichten per copy&paste ins system bringen kannst ohne das du ein echtes device brauchst das du immer wieder flashen musst.

[Shojo]

dein sketch muss eine init nachricht schicken die z,b. so ausschaut:

Code Auswählen Erweitern

INIT DICTIONARY U=UpTime,S=SSID,T=LastReceptionDate,M=Mode,O=OTA-State

Aber ich muss doch auch ein Device mit übergeben das er den Init zuordnen kann?!

Code Auswählen Erweitern

2017-07-04 22:29:52 KVPUDP myKVP UNKNOWNCODE INIT DICTIONARY U=UpTime,S=SSID,T=LastReceptionDate,M=Mode,O=OTA-State

du kannst dir zum testen ein JeeLink device anlegen. dort gibt es ein

Code Auswählen Erweitern

set <name> parse <nachricht>kommando mit dem du nachrichten per copy&paste ins system bringen kannst ohne das du ein echtes device brauchst das du immer wieder flashen musst.

Da behelfe ich mit dem Packet Sender (https://packetsender.com/)

[habeIchVergessen]

bei KVPUDP wird mit dem initialen HTTP-Request (/config?Version=&...) auch das Dictionary gelesen.
Also kannst du alles neu erfinden oder das benutzen, was schon da ist.

[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.

[justme1968]

beim erst maligne empfangen nach dem einschalten sind die init nachrichten doch auch dabei.

das es fälle gibt in denen fhem initial erst mal auf einen aktuellen stand gebracht werden muss bestreite ich ja garnicht. aber ich würde hier auch die INIT nachrichten verwenden und diese nur antriggern.

[habeIchVergessen]

(von ggf. mehreren FHEM-Instanzen) jeweils ein HTTP-GET-Request, der ein UDP-Multicast mit der INIT-Nachricht auslöst.

Was passiert mit der Nachricht, die die Informationen aus dem INIT benötigt, die aber erst asynchron empfangen werden?

[Shojo]

Ok, wo sind wir nun stehen geblieben? 
Ich bin ehrlich gesagt da jetzt nicht mehr ganz mitgekommen..

Ich baue das jetzt dann erst einmal mit der HTTP GET anfrage auf, da es ja so anscheinend gut funktioniere

Gruß
Dennis aka Shojo

[habeIchVergessen]

am einfachsten wäre es, aus EspWifi.ino (s. weiter oben verlinkte KVPUDP) "/config" und "PARSE CONFIG REQUEST"-Nachricht zu kopieren.
Alles andere erfordert zusätzliche Anpassungen an 36_KVPUDP.pm

[Shojo]

So ich habe jetzt mal deinen Source angesehen,
verstehe ich das richtig das dein NodeMCU auch als "Proxy" für andere  Sensoren herhält? 

Und ist das Mapping dann global für den ganzen KVPUPD IODev?

[habeIchVergessen]

verstehe ich das richtig das dein NodeMCU auch als "Proxy" für andere  Sensoren herhält? 

nein

Und ist das Mapping dann global für den ganzen KVPUPD IODev?

nein

ein KVPUDP (in FHEM) verwaltet mehrere NodeMCU-Devices (verschiedene IP/IDs). Pro NodeMCU wird das Mapping gelesen und bei der Verarbeitung von Nachrichten an die empfangenden KeyValueProtocol-Devices weitergereicht.

[Shojo]

OK, danke für deine Geduld.

Ich mache es nun so:

Bei jeden Neustart sendet mein Sensor nun:

Code Auswählen Erweitern

sendMultiCast("REFRESH CONFIG REQUEST");

Die Config die ich dann übergebe sieht dann so aus:

Code Auswählen Erweitern

2017.07.09 19:20:14 3: KVPUDP_Read: got config 192.168.0.114
2017.07.09 19:20:14 3: got config: Version:SKBB.WeatherStation.0.0.0.5,ChipID:13,Dictionary:t=Temperature,d=Dewpoint,h=Humidity,p=Pressure,r=RSSI,w=WifiQuality (28 ms)
2017.07.09 19:20:14 3: myKVP: Received 22 bytes from '192.168.0.114''


Dann kommen die ersten Daten:

Code Auswählen Erweitern

2017.07.09 19:22:01 3: myKVP: Received 59 bytes from '192.168.0.114''
2017.07.09 19:22:01 2: autocreate: define KeyValueProtocol_SKBB.WS_13 KeyValueProtocol SKBB.WS 13

Dann wird allerdings die ersten Readings ohne Mapping angelegt erst da drauf die Messung wird dann korrekt dargestellt.
Was mache ich noch falsch?





 

[habeIchVergessen]

Kein Fehler auf deiner Seite.
Fhem schreibt erst die Attribute und dann die Internals. Also in der ersten Runde fehlt das Mapping-Internal.
Somit kein Ersetzen der Namen.

[Shojo]

Oh, das ist ja unschön

[Shojo]

So habe es erst einmal ohne Mapping gemacht.
Und gehen nun folgt vor ....

Wenn der Sensor startet sendet er als erstes eine "KVP Init Message" mit der dann das  Autocreate angeregt wird :

Code Auswählen Erweitern

OK VALUES SKBB.WWS 1647891
Dann kommt eine "KVP System Info Message":

Code Auswählen Erweitern

OK VALUES SKBB.WWS 1647891 ChipID=1647891,.....
und dann noch einmal die Sensoren, die dann 2 minütlich wiederholt wird:

Code Auswählen Erweitern

OK VALUES SKBB.WWS 1647891 Temperature=22.15,.....

[crispyduck]

Hallo,

Hast du feine Sensoren noch so am laufen? Hast du eventuell auch wo deinen Sketch  veröffentlicht?

Habe mir am WE aus einer alten 10 Tasten Fernbedienung + esp8266 eine wifi Fernbedienung gebaut und bin jetzt am überlegen wie ich das ganze in FHEM integriere, dabei bin ich jetzt auf den Thread gestossen.

Die Tasten, sind mit Dioden + Mosfet so mit dem ESP verbunden das bei tastendruck RST kurz auf GND gezogen wird und gleichzeitig entsprechender, bzw. entsprechende GPIOs auf LOW gezogen werden.

Der ESP wird also bei Tastendruck geweckt, verbindet sich mit dem W-LAN, sendet entsprechend Tastendruck und geht wieder in deepsleep. Das ganze dauert keine 500ms.

Ich habe mich bei meinem ersten sketch jetzt mal an die unzähligen ESP Dash Button Projekte gehalten, und sende pro Taste unterschiedliche konfigurierbare HTTP GET requests.

Funktioniert bei disabelten crfToken, auch mal recht einfach mit FHEM.

Nun überlege ich aber wie soch das eleganter lösen lässt. Und bin bei der Suche nach Möglichkeiten eben hier gelandet.

Das ganze soll vorallem schnell gehen, daher geht das leider auch nicht mit ESPEasy, was ich ursprünglich vor hatte, da es hier einige Sekunden dauert bis die Rules ausgeführt werden.

Danke,
crispyduck

[Shojo]

Moin crispyduck,

Hast du feine Sensoren noch so am laufen?

den Sensor habe ich nicht mehr so im Betrieb.

Hast du eventuell auch wo deinen Sketch  veröffentlicht?

Ob ich den Code noch habe müsste ich mal nachschauen, aber hast Du schon mal an MQTT gedacht?
Ist ein sehr leichtgewichtiges Protokoll!

[crispyduck]

Danke. Ja, du hast recht, ich sollte endlich MQTT einrichten, schiebe das schon eine Weile vor mir her und hatte das unter anderem als Winterprojekt geplant.
Muss mich erst noch bisschen damit beschäftigen, aber ist wohl die bessere Wahl, sollen ja demnächst noch ein paar ESPs dazu kommen.
Darf ich fragen wie du deine Raumsensoren nun betreibst? Immer noch eigener sketch mit MQTT, oder doch schon mit ESPEasy?

Lg
crispyduck

[Shojo]

Nach langem hin und her getestete hab ich einfach keine brauchbare Akkulaufzeit hinbekommen, WLAN braucht halt doch schon etwas mehr Strom.

Jetzt bin ich in jeden Raum mit den TX29 DTH-IT Sensoren (https://amzn.to/2Q2YsEv) glücklich unterwegs.
Am FHEM habe ich das einen JeeLink Clone (https://goo.gl/jtrECR) hängen um die Sensoren zu empfangen.

Gruß
Dennis 

[crispyduck]

Ja, stimmt, für Akku/Batteriebetrieb braucht der ESP doch recht viel.

Mal schauen wie lange meine Fernbedienung mit 2x AAA läuft. Rechne aber bei durchschnittlich 4 Betätigungen pro Tag doch mit mindestens einem Jahr.

Danke auf jeden Fall.
Crispyduck

[Dirk P.]

Hi,
ich versuche schon seit einiger Zeit
NodeMCU für die Davis Vantage Pro2 zu compilieren.

Nur scheitert es jedesmal an der folgenden Stelle:

Siehe Foto

Die wird auch hier im Thread behandelt.

Auch habe ich die fertige *.bin geflasht, nur da geht es nach der Eingabe der ssid und Schlüssel nicht weiter.
Irgendwie stehe ich auf dem Schlauch. Vielleicht kann mich jemand dort runter schubsen...
Ich möchte neu compilieren weil ich zwei zusätzliche Stationen anmelden muss.

[Dirk P.]

Keiner eine Idee?

[habeIchVergessen]

schau mal hier. im 7z-File NodeMCU v0.8b ist auch eine kompilierte Binärdatei für einen Wemos D1 mini.

[Dirk P.]

Danke,
nutzt mir trotzdem nichts, da ich noch 2 Stationen hinzufügen muss....
....und beim compillieren kommt der gleiche Fehler.

Ob ich ihn nun als NodeMCU oder Wemos D1 compilliere macht keinen Unterschied.

[habeIchVergessen]

probier mal Arduino IDE 1.8.9 oder 1.6.13

in Zeile 196 (NodeMCU.ino) steht noch das init-Command (GUI fehlt noch)

Code Auswählen Erweitern


195  // register station, enable receive
196  handleInput('s', true, 0, true, 16);


Zeile 196 kopierst du und änderst dann die Werte. In meinem Beispiel ist es ID 0 (3. Parameter) als Vantage Vue (5. Parameter = 16). Die richtigen Werte findest du in Vantage.h (fhem-master library) Zeile 192 (// Davis VP2 standalone station types) und folgende. Meine 16 (0x10) ist STYPE_VUE.

[habeIchVergessen]

NodeMCU v0.8c (GUI hinzugefügt)