JeeLink v3c/ESP8266 zur Einbindung von Davis Vantage

Begonnen von habeIchVergessen, 15 November 2015, 12:13:53

Vorheriges Thema - Nächstes Thema

habeIchVergessen

Zur Anbindung von Davis Wetter-Sensoren haben HCS und justme1968 das Modul 36_KeyValueProtocol.pm erschaffen. Es erstellt Readings, die aus den Key-Wert-Paaren gelesen werden, die vom Davis-Sketch erzeugt werden. Es ist nicht auf den Einsatz mit Davis beschränkt!

Voraussetzungen:

  • JeeLink v3c (es wird nur der RFM69-Funkchip unterstützt)
  • DAVIS-Sketch (DavisVantage v0.8e.zip 05-09-2020)
  • entsprechender Sensor o.g. Firma (bitte auf 868 MHz Version achten; natürlich nur die Europäer; gilt auch für den JeeLink!!!)

in FHEM:

  • neues JeeLink-Device anlegen

    • define myJeeLink JeeLink /dev/ttyUSB0@57600
    • attr myJeeLink initCommands 0,16s r (mehr Details hier)
    • set myJeeLink reset
  • autocreate erzeugt ein neues KeyValueProtocol_DAVIS_0

    • IODev muss auf myJeeLink gesetzt sein (ggf. manuell)
    • event-on-change-reading sollte auf .* gesetzt werden (sonst gibt es ca. alle 5 Sekunden Updates für die Winddaten, da diese in jedem Datenpaket enthalten sind)
  • z.Z. werden nur Temperature, WindSpeed und WindGust (ab Firmware v0.2) in SI-Einheiten übertragen
  • alle anderen Readings müssen ggf. noch im Sketch korrigiert werden

weitere Informationen zum Sketch (Davis-Protokoll)
ergänzende UserReadings (29.06.2016)

ursprünglicher Text:
ausgehend von VPTools (https://github.com/kobuki/VPTools) und 36_LaCrosse-LaCrosseITPlusReader habe ich einen Sketch zusammen gestrickt, der Daten von Davis Vantage Vue anzeigen kann.

Log:
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:1 f:868296)]
station:0 packets:408/22/94.88 channel:0 rssi:-81 batt:ok windv:2 windd:41 windgust:4 gustref:11
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:3 f:868179)]
station:0 packets:409/23/94.68 channel:2 rssi:-80 batt:ok windv:1 windd:28 rainsecs:30
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:4 f:868410)]
station:0 packets:410/23/94.69 channel:3 rssi:-80 batt:ok windv:2 windd:-9 temp:11.1
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:0 f:868066)]
station:0 packets:411/23/94.70 channel:4 rssi:-82 batt:ok windv:1 windd:7 rh:96.0
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:1 f:868296)]
station:0 packets:412/23/94.71 channel:0 rssi:-82 batt:ok windv:1 windd:21 rain:203
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:2 f:868527)]
station:0 packets:413/23/94.72 channel:1 rssi:-81 batt:ok windv:2 windd:12 rainsecs:30
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:3 f:868179)]
station:0 packets:414/23/94.74 channel:2 rssi:-80 batt:ok windv:2 windd:-1 temp:11.1
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:4 f:868410)]
station:0 packets:415/23/94.75 channel:3 rssi:-80 batt:ok windv:1 windd:-13 vcap:4.2
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:0 f:868066)]
station:0 packets:416/23/94.76 channel:4 rssi:-80 batt:ok windv:1 windd:-13 rain:203
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:1 f:868296)]
station:0 packets:417/23/94.77 channel:0 rssi:-81 batt:ok windv:0 windd:-13 rainsecs:30
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:2 f:868527)]
station:0 packets:418/23/94.78 channel:1 rssi:-80 batt:ok windv:0 windd:-13 temp:11.1
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:3 f:868179)]
station:0 packets:419/23/94.80 channel:2 rssi:-80 batt:ok windv:0 windd:-13 vsolar:527
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:4 f:868410)]
station:0 packets:420/23/94.81 channel:3 rssi:-80 batt:ok windv:0 windd:-13 rain:203
[DavisVantageVP2Vue.0.1 (RFM69 b:2 c:0 f:868066)]
station:0 packets:421/23/94.82 channel:4 rssi:-80 batt:ok windv:0 windd:-13 rainsecs:30

Da ich keine Erfahrung mit fhem-Modulen und deren Zusammenspiel mit JeeLink habe, suche ich Interessierte/Wissende, die gerne weiter helfen wollen.

Billy

FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

HCS

Zitat von: Billy am 16 November 2015, 08:18:35
Vielleicht hilft dir HCS
Nein, leider eher nicht.
Ich habe keine Davis Vantage und so kurz mal weiterhelfen geht hier definitiv nicht, da muss schon einiges mehr getan werden.
Meiner Meinung nach müsste man:
Die Daten vom Sketch so liefern lassen, dass sie in FHEM vernünftig verarbeitet werden können.
Eventuell kann man es in das Format bringen, das auch von WS 1600 verwendet wird.
Dann müsste man vermutlich das 36_JeeLink.pm erweitern, wenn man es dafür verwenden will, und das gehört justme1968.
Oder halt eins für diesen Zweck schreiben.
Und zum Schluss muss man ein Modul finden oder schreiben, das diese Daten darstellt, analog zu 36_LaCrosse.pm.

Sorry, das ist ohne die Hardware zu haben außerhalb von meinem Scope, da will ich mich nicht reinhängen, ich bereue schon, dass ich die WS 1080 Geschichte gemacht habe, ohne eine zu besitzen.

Idealerweise müsste ein FHEM developer gefunden werden, der so eine Station hat und das tun möchte.

justme1968

auf den ersten blick denke ich das es garnicht so kompliziert ist.

wenn der sketch einfach das WS 1600 format liefert sollte auf fhem seite nichts weiter zu tun sein. weder im JeeLink noch im LaCrosse modul.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

HCS

#4
Ja, wenn man auf Informationen wie rainsecs, vcap, vsolar, rssi und was sie sonst noch so sendet, was im WS 1600 Protokoll nicht vorkommt, verzichtet, dann sollte es so machbar sein.
Man muss sich dann auf Temperatur, Feuchte, Windrichtung, Wind-Speed und -Gust, akkumulierte Niederschlagsmenge und Batt OK beschränken.

Das Protokoll sieht so aus:
  /* Format
  OK WS ID  XXX TTT TTT HHH RRR RRR DDD DDD SSS SSS GGG GGG FFF
  |  |  |   |   |   |   |   |   |   |   |   |   |   |   |   |-- Flags *
  |  |  |   |   |   |   |   |   |   |   |   |   |   |   |------ WindGust * 10 LSB (0.0 ... 50.0 m/s)           FF/FF = none
  |  |  |   |   |   |   |   |   |   |   |   |   |   |---------- WindGust * 10 MSB
  |  |  |   |   |   |   |   |   |   |   |   |   |-------------- WindSpeed  * 10 LSB(0.0 ... 50.0 m/s)          FF/FF = none
  |  |  |   |   |   |   |   |   |   |   |   |------------------ WindSpeed  * 10 MSB
  |  |  |   |   |   |   |   |   |   |   |---------------------- WindDirection * 10 LSB (0.0 ... 365.0 Degrees) FF/FF = none
  |  |  |   |   |   |   |   |   |   |-------------------------- WindDirection * 10 MSB
  |  |  |   |   |   |   |   |   |------------------------------ Rain LSB (0 ... 9999 mm)                       FF/FF = none
  |  |  |   |   |   |   |   |---------------------------------- Rain MSB
  |  |  |   |   |   |   |-------------------------------------- Humidity (1 ... 99 %rH)                        FF = none
  |  |  |   |   |   |------------------------------------------ Temp * 10 + 1000 LSB (-40 ... +60 °C)          FF/FF = none
  |  |  |   |   |---------------------------------------------- Temp * 10 + 1000 MSB
  |  |  |   |-------------------------------------------------- Sensor type (1=TX22IT, 2=NodeSensor, 3=WS1080)
  |  |  |------------------------------------------------------ Sensor ID (1 ... 63)
  |  |--------------------------------------------------------- fix "WS"
  |------------------------------------------------------------ fix "OK"

  * Flags: 128  64  32  16  8   4   2   1
                                |   |   |
                                |   |   |-- New battery
                                |   |------ ERROR
                                |---------- Low battery
  */

habeIchVergessen

hatte ich schon in InternalSensors.cpp (LaCrosse-Sourcen) gesehen.
LSB und MSB habe ich gerade nachgeschlagen.

@HCS: danke

Wer oder was definiert denn so ein "Format"?

HCS

Zitat von: habeIchVergessen am 16 November 2015, 18:23:29
Wer oder was definiert denn so ein "Format"?
Ich  ;D ;D ;D

Also im Prinzip erfindet das derjenige, der eine Datenquelle schreibt (z.B. den LaCrosse Sketch) und das dazu passende Modul (z.B. 36_LaCrosse) in FHEM.

HCS

Ich schon wieder  :)

Ich glaube, dass man das Thema noch etwas durchdenken muss, bevor man etwas tut.
Ohne aktuell einen Plan dafür zu haben, wäre zu überlegen, ob man auf der JeeLink-Schiene ein offenes Protokoll hinzufügt, irgendwas in der Art Key/Value, woraus dann ein anstatt 36_LaCosse, 36_EMT7110, usw. zu verwendendes Modul stumpf readings erzeugt. Dann müsste man nicht ständig solche Protokolle erfinden und erweitern.
36_JeeLink gibt es per Clients/Matchlist einfach weiter und 36_UniversalSensor erzeugt, nicht wissend, was die Daten bedeuten, die Readings.

Also so ungefähr (nicht durchdacht, nur mal als Grundidee, IDs usw. müsste man sich überlegen, ...):
Sketch schickt: OK VALUES ID=DV_24;Voltage=5.9;Temperature=21.3;Humidity=56;FunFactor=99

Woraus das Modul dann die entsprechenden readings mit den Werten macht:

Internals:
   DEF        DV_24
   IODev      myJeeLink
   LASTInputDev myJeeLink
   LaCrosse_lastRcv 2015-11-16 18:47:03
   MSGCNT     4450
   NAME       MyCoolSensor
   Readings:
     2015-11-16 18:47:03   Voltage        5.9
     2015-11-16 18:47:03   Temperature        21.3
     2015-11-16 18:47:03   Humidity        56
     2015-11-16 18:47:03   FunFactor           99
Attributes:
  ...


generell sehe ich diese Varianten:
1) das oben Beschriebene (mittlerer Aufwand)
2) Das "WS 1600 Protokoll" verwenden und sich auf dessen Daten einschränken (geringer Aufwand aber eingeschränkt)
3) Eine neue, spezialisierte Schiene mit allem drum und dran für Davis Vantage aufziehen (hoher Aufwand aber exakt auf das Problem zugeschnitten)


Variante 1) könnte evtl. auch für das LaCrosseGateway interessant werden, da es vermutlich mal mehr Sensoren beherschen wird, als der LaCrosse-Sketch und dann auch die Daten loswerden muss, ohne ständig auf FHEM-Seite Module zu erfinden.

Aber wie schon geschrieben, alles erst mal nur Gedankenspiele ...

justme1968

ich finde die idee gut. würde aber direkt eine kleine abwandlung vorschlagen:

der sketch gibt im init eine zuordnung von keys zu reading namen aus. etwas in der art:

<NAME> temperature:1, humidity:2, battery:3,...

und die eigentlichen daten werden dann mit den keys statt den langen reading namen übertragen:

OK VALUES <ID> 1:25.1, 2:60, 3:1,...

dann werden nicht so viele redundanten daten übertragen.

die (hoffentlich) eindeutige device id kann man dann aus <NAME>:<ID> bilden wobei name der sketch name ist.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

habeIchVergessen

#9
ich finde standardisierte Sachen gut.
die Zuordnung von Name/ID zur Bedeutung muss im Konsumenten stattfinden und sollte von 36_JeeLink einfach druchgereicht werden. Sketch und Komponente hinter JeeLink müssen sich verstehen. Ggf. kann z.B. 36_LaCrosse eine Mappingfunktion implementieren, damit JeeLink Klarnamen loggen kann. Die ganzen Strings im Sketch kosten nur kostbaren Platz.

@HCM: ist es techn. möglich, einen BMP180 auf dem JeeLink v3c nachzurüsten? SDA und SCL müssten ja direkt am Atmel abgeriffen werden. Sieht sehr filigran aus.

HCS

Zitat von: justme1968 am 16 November 2015, 19:46:41
der sketch gibt im init eine zuordnung von keys zu reading namen aus. etwas in der art:
<NAME> temperature:1, humidity:2, battery:3,...
und die eigentlichen daten werden dann mit den keys statt den langen reading namen übertragen:
OK VALUES <ID> 1:25.1, 2:60, 3:1,...
dann werden nicht so viele redundanten daten übertragen.
Dann müsste das im init eine Liste für verschiedene Sensoren sein, weil ein Sketch mehrere verschiedene Sensortypen mit unterschiedlichen Daten senden könnte.
Das ist doch aber "nur" die Übertragung auf der Seriellen Schnittstelle, ob da die paar Byte das zu implementieren rechtfertigen?
Es macht die Sache halt komplizierter.

Zitat von: justme1968 am 16 November 2015, 19:46:41
die (hoffentlich) eindeutige device id ...
Ja, ist aber bei LaCrosse auch so. Innerhalb eines Sensor-Typs muss die ID eindeutig sein.

Mal ein fiktiver use case: Das LaCrosseGateway kann außer den LaCrosse Sensoren noch einen Sensortyp empfangen, der die Stellung vom Garagentor sendet und von denen habe ich zwei, einen mit ID 01 und einen mit ID 02 und es sendet Informationen über sich selbst. Und dann gibt es noch den Davis Vantage Sketch von habeIchVergessen (Mann, den Name in eine Satz einzubauen ist abgefahren)
Das LaCrosseGateway sendet:
OK 9 2 130 4 194 125
OK 9 11 130 4 192 125
OK VALUES LCG 10120520 UpTime:12530, ConnectedTo: myCoolNetwork
OK VALUES POSITION 01 Position:open, LastMove:2015-11-17 07:49:57
OK 9 11 130 4 192 125
OK VALUES POSITION 02 Position:closed, LastMove:2015-11-16 17:50:30
OK VALUES LCG 10120520 UpTime:12540, ConnectedTo: myCoolNetwork
OK 9 11 130 4 192 125
usw.

Der Davis Vantage Sketch sendet:
OK VALUES DAVIS 24 Temperature:10.5, Humidity:80
OK VALUES DAVIS 24 Temperature:10.5, Voltage:5.9
OK VALUES DAVIS 24 WindSpeed:20.5, WindDirection:90
OK VALUES DAVIS 24 WindSpeed:18, WindDirection:45
OK VALUES DAVIS 24 Temperature:10.5, WindSpeed:19, WindDirection:90
usw.

Aufbau von OK VALUES ...: OK VALUES <SensorTyp> <ID> <Liste der Werte>

Punkte, die zu beachten sind:
- Ein Sensor sendet nicht immer alle Daten (ist bei der WS 1600 so und bei Davis Vantage wohl auch)
- Das Trennzeichen (Komma oder was auch immer es wird, muss in den Werten escaped werden)
- Die ID darf keine Einschränkung haben, im LaCrosseGateway-Beispiel wäre die ID die Chip-ID des ESP also z.B. 10120520
- Die effektive ID in FHEM wäre dann die Kombination aus <SensorTyp> und <ID> also aus dem Beispiel oben z.B. DAVIS_24 oder LCG_10120520

Als Name für das Modul, das die Werte darstellt, schlage ich 36_Values vor.

@habeIchVergessen: bist Du in der Lage, Deinen Davis Vantage Sketch so zu modifizieren, dass er so ein Protokoll sendet?

justme1968

ZitatDann müsste das im init eine Liste für verschiedene Sensoren sein, weil ein sketch mehrere verschiedene sensortypen mit unterschiedlichen Daten senden könnte.

nein. es braucht nur eine liste in der alle typen jeweils ein mal auftauchen wenn mehr als ein sensortyp temperature sendet soll er ja den gleichen key verwenden. mit <NAME> war der sketch name gemeint. nicht der sensortyp.

auf perl seite ist es nur ein hash lookup. das ist eventuell sogar schneller als die doppelt so langen strings wenn alles klartext ist. die 'paar' bytes werden ja potentiell nicht nur per usb sondern auch per ser2net oder per wlan übertragen.

ich denke es ist nicht wirklich aufwändig und spart potentiell etwas ein.


sensor werte weg zu lassen ist kein problem.


aber wir können ja auch beides vorsehen: wenn der key in der liste auftaucht wird er ersetzt, wenn er nicht auftaucht wird er direkt als reading namen verwendet.

alles andere passt auch.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

habeIchVergessen

Zitat von: HCS am 17 November 2015, 08:41:18
@habeIchVergessen: bist Du in der Lage, Deinen Davis Vantage Sketch so zu modifizieren, dass er so ein Protokoll sendet?

kein Problem

HCS

Zitat von: justme1968 am 17 November 2015, 11:17:10
aber wir können ja auch beides vorsehen: wenn der key in der liste auftaucht wird er ersetzt, wenn er nicht auftaucht wird er direkt als reading namen verwendet.
So machen wir es.
Ich habe mal mit einer initialen Version von 36_Values.pm begonnen.
Und dann mache ich aus dem fiktiven use case vom LaCrosseGateway gleich einen echten, dann habe ich auch was reales, das Daten dafür sendet.

Zur Sicherheit: besteht die Gefahr, dass der Modulname "Values" mit irgend welchen Globals oder sonstwas von FHEM in Konflikt gerät?

justme1968

wie wäre es dem protokoll gleich einen namen zu geben und das modul dann auch so zu nennen. values ist schon sehr allgemein.

wie wäre es mit KVP (key value protocol) oder UniversalKVP?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968