Eigene ESP8266 Raumsensoren

[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