JeeLink v3c/ESP8266 zur Einbindung von Davis Vantage

[JoeALLb]

kurze Rückfrage : brauche ich dann die komplette Wetterstation oder reicht mir die Ausseneinheit?

[habeIchVergessen]

kurze Rückfrage : brauche ich dann die komplette Wetterstation oder reicht mir die Ausseneinheit?

ich habe nur die Vantage Vue Außeneinheit.

[habeIchVergessen]

@HCS:

ich habe ein kurzes Beispiel zum bessern Verständnis zusammen gebaut.

Code Auswählen Erweitern


#include "KVPSensors.h"

#define PROGNAME F("Test")
void setup() {
  Serial.begin(57600);
}

void loop() {
  Serial.print(SensorDataHeader(PROGNAME, 0));
  Serial.print(SensorDataValue(SENSOR_TEMPERATURE_OUTSIDE, (float)(millis() % 37)));
// ohne Trennzeichen zwischen den Key-Value-Paaren
  Serial.print(SensorDataValue(SENSOR_WIND_SPEED, 2.0));
  Serial.print(SensorDataValue(SENSOR_WIND_DIRECTION, 3.8));
// mit Trennzeichen zwischen den Key-Value-Paaren
//  Serial.print(SensorDataValueDelimiter(SENSOR_WIND_SPEED, 2.0));
//  Serial.print(SensorDataValueDelimiter(SENSOR_WIND_DIRECTION, 3.8));
  Serial.println();
 
  delay(527);
}


Damit werden gültige KVP-Nachrichten generiert (mal abgesehen vom Trennzeichen zwischen den Key-Value-Paaren).
Format (Macros) und Key-Werte (Defines) kommen aus der Header-Datei. Somit wären alle Sketches, die nach o.g. Systematik Nachrichten generieren, Protokoll-konform und würden alle den gleichen Key benutzen.

Wenn neue Keys dazukommen/Nachrichten-Format angepasst wird, dann muss der Sketch nur neu kompiliert werden und schon können auch die neuen Key-Value-Paare/das neue Nachrichten-Format gesendet werden.
Das Mapping in 36_KeyValueProtocol.pm entspricht ja ebenfalls den Defines in der Header-Datei. Also könnte aus einer Vorlage der Inhalt der Header-Datei (Defines SENSOR_xxx) und die Mapping-Liste generiert werden.

Nochmal kurz zu den Trennzeichen.
Können wir ein Trennzeichen einführen, das die einzelnen Felder in der Nachricht trennt?

Bsp.:
<HEADER>|<KV-Pair>|<KV-Pair>|<KV-Pair>
OK VALUES DAVIS 0|Channel:1|RSSI:-75|Battery:ok|WindSpeed:3|WindDirection:-58

mir ist ein Beispiel für eine Werteliste eingefallen: Packets:<empfangene>,<fehlende>.
Ist ggf. nur für DAVIS interessant.

[HCS]

Das Mapping in 36_KeyValueProtocol.pm entspricht ja ebenfalls den Defines in der Header-Datei. Also könnte aus einer Vorlage der Inhalt der Header-Datei (Defines SENSOR_xxx) und die Mapping-Liste generiert werden.

Das Ziel ist aber, dass im 36_KeyValueProtocol.pm nicht vorbestimmt ist, was da an Daten kommt. Wenn z.B. das LaCrosseGateway spontan auf die Idee kommt, dass es noch sein Geburtsdatum übermittelt, will ich einfach ein Reading haben, ohne sonst noch etwas tun zu müssen.
Eine vorherige Absprache des Protokolls zwischen 36_KeyValueProtocol.pm und irgend einem Sketch macht das "Universal" zunichte, zumindes wenn es vorab durch irgend welche Dateien geschehen muss.

Wenn ich heute Nacht im LaCrosseGateway einbaue, dass es das sendet:

Code Auswählen Erweitern

OK VALUES LGW 25e38 UpTime:125645,Status:connected,USB-Voltage:4.98
OK VALUES LGW 25e38 UpTime:125655,Status:connected,USB-Voltage:5.01
usw.
brauche ich auf FHEM-Seite absoult nichts tun. Sobald das erste Paket kommt, wird per Autocreate ein Device "KeyValueProtocol_LGW_25e38" incl FileLog angelegt und es entstehen die Readings UpTime ,Status und USB-Voltage und deren Werte laufen ins FileLog.
Und wenn ich es morgen Nacht auf

Code Auswählen Erweitern

OK VALUES LGW 25e38 UpTime:125655,Status:connected,USB-Voltage:5.01,ReceivedPackets:1250
erweitere, bekomme ich, ohne in FHEM etwas tun zu müssen, noch ein Reading "ReceivedPackets" dazu.

Das Dictionary war ja der justme1968 Wunsch, um die übertragene Datenmenge pro Paket zu reduzieren, und nicht, um ein Datenformat vorzudefinieren.
Das könnte der Sketch am anfang (also am Ende von void init(void)) eimalig senden, z.B. so:

Code Auswählen Erweitern

OK DICTIONARY 1=Temperature,2=Humidity,3=WindSpeed
Das JeeLink Modul müsste das dann als Dictionary erkennen und in ein internal packen, dass alle KeyValueProtocol Instanzen es sich bei ihrem IODev, sofern esr vorliegt, holen können und die Umsetzung zu machen. Zusätzlich könnte es dann im 36_KeyValueProtocol noch das Attribut geben, mit dem der Anwender das Mapping überschrieben kann.

Dazu kommt, dass die Datenquelle nicht unbeding c++ und noch nicht mal unbedingt Arduino sein muss. Das ist irgend etwas, das an der Seriellen Daten abliefert und um mit KeyValueProtocol.pm universell zu sein, mache ich fest die Augen zu, dass ich nicht sehe, wie die auf der Quellseite entstehen.

Nochmal kurz zu den Trennzeichen.
Können wir ein Trennzeichen einführen, das die einzelnen Felder in der Nachricht trennt?

Haben sir doch, aktuell das Komma.
OK VALUES DAVIS 0 Channel:3, RSSI:-81, Battery:ok,
Die Leerzeichen sind nicht erforderlich, aber uach nicht störend, habe ich nur reingetippt, zur besseren Lesbarkeit.

[habeIchVergessen]

Wenn z.B. das LaCrosseGateway spontan auf die Idee kommt, dass es noch sein Geburtsdatum übermittelt, will ich einfach ein Reading haben, ohne sonst noch etwas tun zu müssen.

Ist aus meiner Sicht eine Erweiterung des Protokolls und sollte als solche dokumentiert werden. Ein unmappedReadingXXX (s.u.) wäre ein klares Indzis und würde eine entsprechende Aktion zur Folge haben. Alle anderen existierenden Sketches, die das Reading nicht benutzen, sind davon nicht betroffen (Compiler lässt nur die verwendeten Defines übrig).

Das JeeLink Modul müsste das dann als Dictionary erkennen und in ein internal packen, dass alle KeyValueProtocol Instanzen es sich bei ihrem IODev, sofern esr vorliegt, holen können und die Umsetzung zu machen. Zusätzlich könnte es dann im 36_KeyValueProtocol noch das Attribut geben, mit dem der Anwender das Mapping überschrieben kann.

JeeLink generiert die Readings? Wenn ja, dann wäre eine zentrale Definition um so erforderlicher!

Haben sir doch, aktuell das Komma.
OK VALUES DAVIS 0 Channel:3, RSSI:-81, Battery:ok,
Die Leerzeichen sind nicht erforderlich, aber uach nicht störend, habe ich nur reingetippt, zur besseren Lesbarkeit.

der kleine aber feine Unterschied ist
OK VALUES DAVIS 0hierChannel:3, RSSI:-81, Battery:ok,

wenn ich Key-Value-Paare schreibe, dann will ich nicht wissen, ob ich das Trennzeichen senden muss oder nicht (z.B. Sensor sendet nicht alle Readings zur gleichen Zeit).

Ich finde die einheitliche Definition von Format und Sensortypen sinnvoll. Sollten unbekannte Readings über die Leitung gehen, können diese immer noch als solche markiert werden (z.B. unmappedReading<USB-Voltage|123>).

[habeIchVergessen]

Das Dictionary ...
Das könnte der Sketch am anfang (also am Ende von void init(void)) eimalig senden, z.B. so:

halte ich für ungeschickt, da der Sketch das komplette Mapping (seiner Readings) enthalten muss. Meiner Meinung nach nur verschwendete Bytes!

[HCS]

Sorry, aber das ist mir zu speziell, zu sehr konfiguriert und unsere Ansichten, was das machen soll, liegen dann so weit auseinander, dass Du wohl eher ein 36_DavisVantage.pm schreiben solltest, das genau das tut, was Du Dir vorstellst.

Das 36_JeeLink müsstest Du, so wie es ist, verwenden könnnen, nur musst Du dann die Attribute MatchList und Clients entsprechend setzten, dass zu Deinem Modul dispatched wird.

[habeIchVergessen]

ich muss zugeben, dass ich das endende "," in deiner Beispielnachricht überlesen habe. Somit liegen unsere Vorschläge nicht weit auseinander und mein Einwand ist hinfällig.
weiterhin kann ich nicht behaupten, über die Interna von FHEM groß Ahnung zu haben.
Trotzdem gehört aus meiner Sicht zur Definition eines Protokolls nicht nur die Aussage wie ich Daten verschicke sondern auch was.

Wer generiert den nun die Readings (36_JeeLink oder 36_KeyValueProtocol)?
Würden nicht sogar beide von zentralen Definition profitieren?

Trotzdem ein großes Dankeschön für dein Engagements.

[HCS]

Trotzdem gehört aus meiner Sicht zur Definition eines Protokolls nicht nur die Aussage wie ich Daten verschicke sondern auch was.

Dann müsste im der RFC 2460 drin stehen, dass Dein letzter Beitrag im IP-Protokoll vorgesehen ist 

So, nun nun ernsthaft:

Wer generiert den nun die Readings (36_JeeLink oder 36_KeyValueProtocol)?

Grob, es gibt noch Details:
36_JeeLink ist das Modul, das die Kommunikation mit der Schnittstelle abwickelt, ohne die Bedeutung der Information zu kennen und gemäß seiner Matchlist eingehende Pakete an die Module verteilt, die dafür zuständig sind.

Die Matchlist sieht z.B. so aus (schon mal für ein DavisVantage Modul erweitert:

Code Auswählen Erweitern


{ "1:PCA301" => "^\\S+\\s+24", "2:EC3000" => "^\\S+\\s+22", "3:RoomNode" => "^\\S+\\s+11", "4:LaCrosse" => "^(\\S+\\s+9 |OK\\sWS\\s)", "5:AliRF" => "^\\S+\\s+5 ", "6:EMT7110" => "^OK\\sEMT7110\\s", "7:CustomSensorExample" => "^OK\\sCC\\s" , "8:DavisVantage" => "^OK\\sDAVISVANTAGE\\s" }
Wenn auf das eingegangene Datenpaket die regex "^(\\S+\\s+9 |OK\\sWS\\s)" passt, dann wird das Paket an das LaCrosse Modul zugestellt.
Wenn auf das eingegangene Datenpaket die regex "^OK\\sDAVISVANTAGE\\s"" passt, dann würde das Paket an das DavisVantage Modul zugestellt.
36_JeeLink ist also der Verteiler, dem es egal ist, was die Daten hinten raus bedeuten.

Module wie 36_LaCrosse, 36_EMT7110 oder dann halt ein 36_DavisVantage erhalten in ihrer "Parse" Methode das Datenpaket und die sind dann dafür zuständig, den Inhalt der Daten zu verstehen und zu dekodieren und daraus irgend welche Reading zu berechnen.

Das läuft mit dem 36_KeyValueProtocol erst mal auch genau so, nur dass das 36_KeyValueProtocol auch keine Logik enthalten soll, was die Daten bedeuten und welche kommen sondern dumm und stump readings draus macht.

Der Unterschied ist also: Der LaCrosse Sketch und ähnliche codieren Temperatur, Feuchte usw. zu so etwas zusammen: "OK 9 41 1 4 185 60", 36_JeeLink reicht es an 36_LaCrosse weiter und 36_LaCrosse dekodiert es wieder und macht Readings Tempertur 10°C, Feuchte 90% usw. draus.

Für 36_KeyValueProtocol schickt eine Datenquelle Klartext in form von KVP, somit wird keine spezielle Logik gebaucht, wie das zu verstehen und zu entschlüsseln ist, und es funktioniert mit allem, was in der Form geschickt wird.

Weitere Infos zu zweistufigen Modulen findet man im wiki: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module

[JoeALLb]

Also ich wäre absoluter Fan von "36_KeyValueProtocol" und mir fallen direkt ein /zwei einsatzgebiete dazu ein. Wenn ihr das also umsetzen würdet, könnte man in zukunft sicher auf das ein oder andere eigenständige FHEM-Modul verzichten und ws viel schneller und einfacher umsetzen!!

[HCS]

Also ich wäre absoluter Fan von "36_KeyValueProtocol"

Bin auch ein Fan davon 

... könnte man in zukunft sicher auf das ein oder andere eigenständige FHEM-Modul verzichten und ws viel schneller und einfacher umsetzen!!

Das war ja genau der Gedanke dahinter.

Wenn ihr das also umsetzen würdet ...

Ich mache das 36_KeyValueProtocol auf alle Fälle, aber so wie ganz oben beschrieben. Ich kann es nämlich auch (in dieser Variante) gebrauchen.
Muss noch mit Justme1968 den Dictionary-Teil klären, wie wir das machen, dann ist es schon fast fertig (mal von Feintuning abgesehen).
Wenn wir mal durch das Gröbste durch sind, checke ich es natürlich auch ein.
Mein Vorschlag, zur Erinnerung war (Namensgebung ist diskutierbar):
Sketch schickt (optional) in seiner Initialisierung "OK DICTIONARY 1=Temperature,2=Humidity,3=WindSpeed"
und das JeeLink Modul packt das stumpf, ohne es zu verstehen oder etwas mit zu tun, in ein Internal "Dictionary", aus dem sich die 36_KeyValueProtocol Instanzen bedienen.
Zusätzlich bekommt 36_KeyValueProtocol ein Attribut "Dictionary", in dem man die Umsetzung überschreiben kann.
Funktionieren wird es aber auch, wenn der Sketch kein Dictionary sendet, dann werden die Readings genau so, wie sie übermittelt werden.

@habeIchVergessen: geh mal in Dich, ob Du wirklich ein Modul schreiben willst. Meiner Meinung nach kannst Du das hier verwenden und ein ca. 100 Byte Dictionary auf einem 32K Atmega386 in PROGMEM packen kann nicht der Hindernisgrund sein. Andererseits hast Du mit einem spezialisierten 36_DavisVantage auf FEHM Seite alle Möglichkeiten, auf die Daten noch Einfluss zu nehmen.

[JoeALLb]

Wie sieht es mit der anderen Richtung aus,  kann man Einstellungen/Parameter für den Sketch auch darüber generalisieren?

[HCS]

Wie sieht es mit der anderen Richtung aus,  kann man Einstellungen/Parameter für den Sketch auch darüber generalisieren?

Das sollte doch wie gehabt mit dem InitCommands Attribut von JeeLink device machbar sein.
Damit werden ja jetzt schon die ganzen Sketche (LaCrosse, PCA301, ...) nach Anwenderwunsch konfiguriert.

[habeIchVergessen]

@HCS:
ich fange mal mit dem an, wo ich bis jetzt die meiste Zeit verbraucht habe: der Sketch

ich finde es sehr gut, eine Übersicht über alle bekannten Readings an einer zentralen Stelle zu haben (Header-File).
Weiterhin gefällt mir, das der Compiler nur übrig lässt, was im Code referenziert wird.
Die Lesbarkeit/Verständlichkeit ist ebenfalls gut. Das Nachrichtenformat kümmert mich nicht, da durch Macros abgedeckt.

kommen wir zu dem Teil, zu dem meine Meinung eher uninteressant ist, da nicht durch profundes Fachwissen untermauert: FHEM

ich habe ca. 1h mit 36_LaCrosse.pm zugebraucht und bei mir ist der Eindruck hängen geblieben, dass eine wilde Schaar von Arrays beackert wird, wobei nicht durch das Code-Studium ersichtlich wird, was passiert.

Ergo: muss ich mich auf das verlassen, was Wissende in kurzer Zeit auf die Beine stellen können.

zum Protokoll
- Format stimme ich uneigeschränkt zu
  <Header> = "OK VALUES <DeviceType> <DeviceID>"
  <Separator Header Key-Value-Felder> = " "
  <Key-Value-Feld> = "<Key-Wert>:<Value-Wert>," (0 .. n mal?)
- Key-Wert
  kann damit leben, wenn jede Hardware-Implementierung ihr eigens Süppchen koch. Würde aber
  eine Vereinheitlichung klar bevorzugen.

als nächstes versuche ich eine Lösung für das DICTIONARY im Sketch zu finden. sprich die Liste aller Readings mit denen im Code zu verheiraten ohne die o.g. Vorteile aufzugeben.

[habeIchVergessen]

hab mir die Zeit genommen und 36_KeyValueProtocol.pm und 36_JeeLink.pm in meine Installation kopiert.
Hier die Ausgabe von list KeyValue.*

Code Auswählen Erweitern


fhem> list KeyValue.*
Internals:
   CFGFN
   DEF        DAVIS 0
   ID         DAVIS_0
   IODev
   LASTInputDev myJeeLink
   MSGCNT     143
   NAME       KeyValueProtocol_DAVIS_0
   NR         255
   STATE      Initialized
   TYPE       KeyValueProtocol
   model      DAVIS
   myJeeLink_MSGCNT 143
   myJeeLink_RAWMSG OK VALUES DAVIS 0 Channel:1,RSSI:-75,Battery:ok,WindSpeed:1,WindDirection:-26,Humidity:74.00,
   myJeeLink_TIME 2015-11-18 20:21:19
   Readings:
     2015-11-18 20:21:19   Battery         ok
     2015-11-18 20:21:19   Channel         1
     2015-11-18 20:21:19   Humidity        74.00
     2015-11-18 20:21:19   RSSI            -75
     2015-11-18 20:21:11   Rain            63
     2015-11-18 20:21:03   RainSecs        -1
     2015-11-18 20:21:16   Temperature     51.90
     2015-11-18 20:20:38   VCap            6.41
     2015-11-18 20:19:57   VSolar          1
     2015-11-18 20:21:19   WindDirection   -26
     2015-11-18 20:21:19   WindSpeed       1
Attributes:
   room       KeyValueProtocol


funktioniert gut soweit.

@HCS: die Einheiten sind °F (nicht Death Valley), mph, Rain ist ein TipCount vom Messlöffel, usw.