JeeLink v3c/ESP8266 zur Einbindung von Davis Vantage

[HCS]

...und auch gleich noch KeyValueProtocol in den clients ergänzt. dann sollte autocreate auch gehen.

Hatte ich gar nicht gemerkt, dass die clients nicht schon drin waren 

statt es in 36_JeeLink einzubauen würde ich aber vorschlagen es auch in 36_KeyValueProtocol zu erledigen. dann ist alles in einem modul zusammen. ich würde dann stecke dann "77:KeyValueProtocol" => "^OK\\sDICTIONARY\\s", noch mit in die machtList einbauen.

Bist Du sicher, dass das so geht?
Der Sketch schickt in seiner Init einmal nach dem Öffnen der Schnittstelle oder nach einem Reset das Dictionary.
Wenn er dann irgend wann etwas empfängt und Daten liefert, wird ein 36_KeyValueProtocol angelegt. Das bekommt dann aber nie ein OK DICTIONARY

[justme1968]

es müsste gehen wenn das dictionary als letztes ganz am ende der  Initialisierung kommt. wenn es noch nicht direkt geht baue ich es ein.

das problem das du ansprichst ist eher eins das bei autocreate immer mindestens eine nachricht verloren geht.

ich muss mal überlegen wie wir das machen...

[HCS]

habe mich ein wenig in der Parse-Methode ausgetoppt (nur noch 2 regexp).

Ja, nur funktioniert sie nun nicht mehr richtig. Fast alle meine Testdaten erzeugen damit Readings, die nicht korrekt sind.

[habeIchVergessen]

ggf. werden Readings übersprungen. würde gern mit deinen Daten testen.

den Sketch habe ich für Temperatur und Windgeschwindigkeit angepasst. Für die anderen Readings muss ich mir noch überlegen, was damit zu machen ist. Den tipcount von Regensensor umrechnen wird nicht einfach, da keine historischen Daten verfügbar.

[HCS]

ggf. werden Readings übersprungen. würde gern mit deinen Daten testen.

Die stehen im Quellcode oben unter der Überschrift "# Test data"

Warum hast Du die parse eigentlich geändert? Gab es irgend welche Daten, die sie nicht korrekt verarbeitet hat?

den Sketch habe ich für Temperatur und Windgeschwindigkeit angepasst. Für die anderen Readings muss ich mir noch überlegen, was damit zu machen ist. Den tipcount von Regensensor umrechnen wird nicht einfach, da keine historischen Daten verfügbar.

Regen: da kann der Sketch schlicht den akkumulierten Niederschlag in mm liefern und das dürfte auch das sein, was die Station sendet oder schlimmstenfalls ist es tips x tip-Inhalt-in mm, das ist bei der WS 1600 z.B. auch so.
Um den Niederschlag der letzten Stunde, Tag, Woche, Monat, Jahr, ... zu bekommen verwendet man dann das FHEM-Modul rain oder statistics, das einem diese gerechneten Werte als Readings dazupackt.

[justme1968]

mir ist noch nichts gutes eingefallen was das verschlucken der ersten nachricht(en) beim autocrate angeht.

vorschlag: 36_JeeLink legt die DICTIONARY nachricht einfach 1:1 in einem internal initMessages ab. 36_KeyValueProtocolkann dann  einfach am ende der DefFn in $hash->{IODev}->{initMessages} nachschauen was der sketch gesendet hat.

wie wäre es statt OK DICTIONARY besser INIT DICTIONARY zu verwenden? dann würde ich alle INIT nachrichten in das internal stecken. das wäre dann eine generische lösung die man vermutlich noch für andere zwecke und für andere sketches verwenden kann?

schau dir mal die angehängte version an. da habe ich mal eine erste version eingebaut.

gruss
  andre

edit: ist inzwischen eingecheckt

[HCS]

vorschlag: 36_JeeLink legt die DICTIONARY nachricht einfach 1:1 in einem internal initMessages ab. 36_KeyValueProtocolkann dann  einfach am ende der DefFn in $hash->{IODev}->{initMessages} nachschauen was der sketch gesendet hat.

Ja, prima, so hatte ich es mir vorgestellt.

wie wäre es statt OK DICTIONARY besser INIT DICTIONARY zu verwenden? dann würde ich alle INIT nachrichten in das internal stecken. das wäre dann eine generische lösung die man vermutlich noch für andere zwecke und für andere sketches verwenden kann?

Finde ich gut.

schau dir mal die angehängte version an. da habe ich mal eine erste version eingebaut.

Fast genau das hatte ich hier schon mal zum experimentieren drin 
Sollten wir das evtl. noch mit Trennzeichen versehen, dass wenn mehrere INIT ... reinkommen, die sich nicht nahtlos zusammenmischen?
Oder evtl. noch besser ein hash (key das, was nach INIT kommt, hier also DICTIONARY), dann könnte ein Modul sehr einfach schauen, ob ein DICTIONARY oder ein sonstwas hinterlegt wurde, das es gebrauchen kann.

Aber generell würde ich sagen, dass wir es so durchziehen.

[habeIchVergessen]

@HCS: folgende Nachricht kann nicht richtig geparst werden

Code Auswählen Erweitern


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


ggf. sollte ein anderes Zeichen zum Trennen der Felder definiert werden (z.B. |).

[HCS]

Warum?
Also ich meine damit warum ausgerechnet die pipe?

[justme1968]

{initMessages} sollte eigentlich die newlines noch enthalten und zeilenweise aufgebaut sein. wenn die fehlen würde ich sie einfügen.

ich würde gerne so wenig wie möglich vorverarbeitung machen. der hash hätte auch noch den nachteil das er in der detail ansicht nicht zu sehen ist.

[HCS]

{initMessages} sollte eigentlich die newlines noch enthalten und zeilenweise aufgebaut sein. wenn die fehlen würde ich sie einfügen.

ich würde gerne so wenig wie möglich vorverarbeitung machen. der hash hätte auch noch den nachteil das er in der detail ansicht nicht zu sehen ist.

Zeilenweise geht OK, wenn Du den Umbruch ggf. nachträgst.
Der Vorteil "lesbar" ist unschlagbar.

[justme1968]

kannst du mal bitte schauen warum das newline verloren geht und ob das besser funktioniert:

Code Auswählen Erweitern

   if( $dmsg =~ /^INIT / ) {
     $hash->{initMessages} .= "\n" if( $hash->{initMessages} );
     $hash->{initMessages} .= $dmsg;
     return; 
   }         


[HCS]

kannst du mal bitte schauen warum das newline verloren geht ...

So geht es.

Ich glaube, da geht kein newline verloren. Ich muss es mal von einem Sketch schicken lassen, was dann passiert. Der schickt es ja dann mit einem \n am Ende.
Das liegt evtl. an meiner "set myJeeLink parse INIT DICTIONARY T=Temperature,H=Humidity" Testerei, dass da dann keins hinten dran ist.

Wir machen das so: ich baue es mal in den Sketch ein und teste es durch und dann sehen wir, ob wir das \n reinbauen müssen oder nicht.

[justme1968]

ja. das ist die ursache. das set raw muss eigentlich ein newline anhängen

[habeIchVergessen]

Also ich meine damit warum ausgerechnet die pipe?

kann auch ein & sein (wie bei HTTP). hauptsache es ist definiert.