JeeLink v3c/ESP8266 zur Einbindung von Davis Vantage

[HCS]

...
   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
funktioniert gut soweit.

Eben, und ohne etwas in FHEM dafür tun zu müssen, einfach so ...

Ich habe jetzt auch den Algo bebacken bekommen, dass das Trennzeichen in den KVPs (also das Komma) in den Werten vorkommen darf, ohne dass es vom Sketch escaped werden muss.

Der Sketch kann nun also z.B. das senden:
OK VALUES LGW 12345 UpTime:2345678, SSID:MyCoolNetwork,LastReceiveTime:2015-11-17 13:39:14,Mode:OK,Connected,Cool,OTA:Ready

Ergibt:

Code Auswählen Erweitern

...
   Readings:
     2015-11-19 13:14:11   LastReceiveTime 2015-11-17 13:39:14
     2015-11-19 13:14:11   Mode            OK,Connected,Cool
     2015-11-19 13:14:11   OTA             Ready
     2015-11-19 13:14:11   SSID            MyCoolNetwork
     2015-11-19 13:14:11   UpTime          2345678


[HCS]

Das "Mapping" Attribut wäre dann auch drin.

Beispiel:

Mapping:

Code Auswählen Erweitern

attr KeyValueProtocol_LGW_12345 Mapping U=UpTime,S=SSID,T=LastDateReception,M=Mode,O=OTA-State

Eingehende Daten

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

Ergebnis:

Code Auswählen Erweitern

Internals:
   DEF        LGW 12345
   ID         LGW_12345
   IODev      myJeeLink
   LASTInputDev myJeeLink
   MSGCNT     11
   NAME       KeyValueProtocol_LGW_12345
   NR         235
   STATE      Initialized
   TYPE       KeyValueProtocol
   model      LGW
   myJeeLink_MSGCNT 11
   myJeeLink_RAWMSG OK VALUES LGW 12345 U:2345678, S:MyCoolNetwork,T:2015-11-17 13:39:14,M:OK,Connected,Cool,O:Ready
   myJeeLink_TIME 2015-11-19 20:20:50
   CHANGETIME:
   Readings:
     2015-11-19 20:20:50   LastDateReception 2015-11-17 13:39:14
     2015-11-19 20:20:50   Mode            OK,Connected,Cool
     2015-11-19 20:20:50   OTA-State       Ready
     2015-11-19 20:20:50   SSID            MyCoolNetwork
     2015-11-19 20:20:50   UpTime          2345678
Attributes:
   IODev      myJeeLink
   Mapping    U=UpTime,S=SSID,T=LastDateReception,M=Mode,O=OTA-State
   room       KeyValueProtocol

Was jetzt noch fehlt:
- Mapping wird optional vom Sketch bereitgestellt
- Attribut, um das Mapping verpflichtend zu machen, bedeutet, es werden nur die Readings angelegt, die im Mapping stehen, egal was der Sketch sonst noch schickt
- commandref

[habeIchVergessen]

in einem Macro können Parameter mittels ## um ein Suffix ergänzt werden

Code Auswählen Erweitern


#define SensorName(id)                  id ## _NAME

#define SENSOR_TEMPERATURE_NAME         F("Temperature")
#define SENSOR_TEMPERATURE              (byte)  1


SensorName(SENSOR_TEMPERATURE) liefert den Text aus SENSOR_TEMPERATURE_NAME zurück. Damit sollte das DICTIONARY realisierbar sein. Auch der Compiler ist so schlau und nimmt nur die Strings mit, die auch referenziert werden.
Dateien zum Spielen im Anhang (in der ino-Datei im setup() Zeilen mit SENSOR_TESTXXX kommentieren).

[habeIchVergessen]

Mapping scheint nicht zu funktionieren

Code Auswählen Erweitern


attr KVP Mapping a:Column1,b:Column2,c:Column3
set myJeeLink parse OK VALUES Test 1 a:Value1,b:Value2,d:Value4

fhem> list KVP
Internals:
   CFGFN
   DEF        Test 1
   ID         Test_1
   IODev
   LASTInputDev myJeeLink
   MSGCNT     4
   NAME       KVP
   NR         305
   STATE      Initialized
   TYPE       KeyValueProtocol
   model      Test
   myJeeLink_MSGCNT 4
   myJeeLink_RAWMSG OK VALUES Test 1 a:Value1,b:Value2,d:Value4
   myJeeLink_TIME 2015-11-19 21:32:43
   Readings:
     2015-11-19 21:25:34   1               Value1
     2015-11-19 21:25:34   2               Value2
     2015-11-19 21:25:34   3               Value3
     2015-11-19 21:25:34   4               Value4
     2015-11-19 21:32:43   a               Value1
     2015-11-19 21:32:43   b               Value2
     2015-11-19 21:28:35   c1              Value1
     2015-11-19 21:28:35   c2              Value2
     2015-11-19 21:28:35   c4              Value4
     2015-11-19 21:32:43   d               Value4
Attributes:
   Mapping    a:Column1,b:Column2,c:Column3


-rw-r--r-- 1 root root 5519 Nov 19 21:21 FHEM/36_KeyValueProtocol.pm
md5: 9a16f828899497f57381efd7cb753a2c


mache ich was falsch? attr mit endendem , ändert auch nichts.

[HCS]

Du musst es auch mit = angeben

a=Column1,b=Column2,c=Column3

[habeIchVergessen]

Danke

[habeIchVergessen]

Sensor-Definition auf enum geändert.  Nach meinem Dafürhalten sehr übersichtlich und leicht generierbar.

[habeIchVergessen]

habe mich ein wenig in der Parse-Methode ausgetoppt (nur noch 2 regexp).
Eigentlich wollte ich mich umschauen, ob und wie mittels Dispatch an ein weiteres Modul durchgeleitet werden kann.

Ist mir aktuell noch zu heiß!

@HCS: Schwebt dir Ähnliches in LaCrosse Gateway vor?

Mal als Idee ins Blaue gesponnen:
Ein Modul, das spez. die Reading von Davis versteht (Rain usw.) , registriert sich bei der KeyValueProtocol-Instanz und bekommt von da an alle Reading per Dispatch durchgestellt. Könnte so etwas funktionieren?

[justme1968]

das geht schon... die frage ist nur warum? wenn die werte aus dem sketch nicht für modul a sondern für modul b sind ist es besser sie direkt an modul b zu senden ohne den umweg über a.

gruss
  andre

[habeIchVergessen]

noch ein perl Brocken, um gegen ein Default-Mapping Liste zu prüfen:

Code Auswählen Erweitern


my %mapping = (
  1 => 'Temperature',
  2 => 'Pressure',
  3 => 'Humidity',
  4 => 'WindSpeed',
  5 => 'WindDirection',
  6 => 'WindGust',
  7 => 'WindGustRef',
  8 => 'Rain',
  9 => 'RainSecs',
10 => 'Solar',
11 => 'VoltageSolar',
12 => 'VoltageCapacity',
13 => 'SoilLeaf',
# techn. Readings
220 => 'Channel',
221 => 'Battery',
222 => 'RSSI',
# diagnostic Readings
255 => 'PacketDump'
);
my @knownMappingValues = sort { $a cmp $b } values %mapping;

$key = (( exists($mapping{$key}) ? $mapping{$key} : ($key  ~~ @knownMappingValues ? $key : "unmappedReading" . $key));


damit ließe sich die Header-Datei komplett generien

Code Auswählen Erweitern


# hier fehlt noch der statisch Teil
print "\nlist of known sensors\n";
my $cnt = 0;
foreach my $key (sort { $a <=> $b } keys %mapping) {
  printf "%s\t%-30s\t=\t(byte)%3d\n", ($cnt ? "," : ""), $mapping{$key}, $key;
  $cnt++;
}
# hier fehlt noch der statisch Teil


[habeIchVergessen]

das geht schon... die frage ist nur warum? wenn die werte aus dem sketch nicht für modul a sondern für modul b sind ist es besser sie direkt an modul b zu senden ohne den umweg über a.

dann kann in FHEM bestimmt werden, welche Maßeinheit vom Sketch kommt (Benutzer stellt fest) und konfiguriert die entsprechende Umrechnung (z.B °F in °C).
Oder beispielsweise die Berechnungen vom Regenvolumen sollte bei jedem Hardware-Hersteller etwas anders sein und ist somit nicht für KeyValueProtocol geeignet, oder?

[HCS]

Eigentlich wollte ich mich umschauen, ob und wie mittels Dispatch an ein weiteres Modul durchgeleitet werden kann.

@HCS: Schwebt dir Ähnliches in LaCrosse Gateway vor?

Nee. Da bin ich ganz bei justme1968. Wozu soll es gut sein?
Wenn Du ein spezialisiertes Modul willst, dann mach ein 36_DavisVantage,  nimm die 20 Zeilen Code aus dem 36_KeyValueProtocol und verarbeite die Daten mit Umrechnung und was auch immer.

dann kann in FHEM bestimmt werden, welche Maßeinheit vom Sketch kommt (Benutzer stellt fest) und konfiguriert die entsprechende Umrechnung (z.B °F in °C).
Oder beispielsweise die Berechnungen vom Regenvolumen sollte bei jedem Hardware-Hersteller etwas anders sein und ist somit nicht für KeyValueProtocol geeignet, oder?

Der Sketch ist für eine bestimmte Hardware, also kann der Sketch die Löffel, Wippen oder was auch immer schon in Liter umgerechnet abliefern.
Temperaturen kann er in °C liefern, wenn einem dass tatsächlich nicht zusagt, kann man es in Modul immer noch mit einem UserReading umrechnen.
Wenn man tatsächlich ansagen will, wie der Sketch Daten schickt, dann kann man dem Sketch Commands beibringen (siehe LaCrosse Sketch) und die im JeeLink Modul in den InitCommands definieren.
Und dann kann 36_KeyValueProtocol prima dumm bleiben.

[justme1968]

das einheiten thema ist problematisch und es gibt mehrere diskussionen dazu. im prinzip sollten alle fhem devices si einheiten in den readings verwenden und das jeweilige frontend ist dafür zuständig werte in der vom benutzer gewünschten und konfigurierten einheit anzuzeigen. in fhemweb kannst du die präsentation zur zeit über stateFormat oder in einer readingsGroup über valueFormt und valueSuffix anpassen.


intern müssen gleiche reading typen immer in der gleichen standardisierten einheit gespeichert. wenn das in den readings gemischt wird kommst du hinterher in teufels küche weil du es nie wieder auseinander dröseln kannst wenn die einheit nicht mitgeführt wird.

das konfigurieren der zu verwenden einheiten in den frontends ist leider noch nicht so weit, wenn du aber jetzt auf readings ebene damit anfangen würdest kannst du das später nicht mehr gerade ziehen.


wenn du dir die kette gerät -> sketch -> fhem intern -> frontend anschaust muss alles zwischen sketch und fhem standardisiert sein. der sketch ist dafür zuständig die geräte werte in das einheitliche fhem interne format zu wandeln, das frontend ist dafür zuständig die internen werte für den benutzer aufzubereiten.

wenn auf hardware seite bestimmte geräte unterschiedlich zu interpretierende werte liefern sollte das entweder im sketch auf (vergleichbare) si einheiten (der davon abgeleitete) umgerechnet werden oder es müssen unterschiedliche benannte readings dafür verwendet werden.

[HCS]

@justme: bauen wir das Dictionary (OK DICTIONARY 1=Temperature,2=Humidity,...) noch ein?
Wenn ja, dann mache ich noch die commandref und dann ist das Ding erledigt und ich checke es ein.

[justme1968]

ich finde es immer noch gut

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.

gruss
  andre

ps: hab es mal so eingecheckt und auch gleich noch KeyValueProtocol in den clients ergänzt. dann sollte autocreate auch gehen.