Zur Anbindung von Davis Wetter-Sensoren (http://www.davisnet.com/weather/products/index.asp) 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 (https://forum.fhem.de/index.php/topic,44092.msg1083313.html#msg1083313))
- 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) (http://forum.fhem.de/index.php/topic,44092.msg364599.html#msg364599)
- 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) (http://forum.fhem.de/index.php/topic,44092.msg364606.html#msg364606)
ergänzende UserReadings (29.06.2016) (http://forum.fhem.de/index.php/topic,44092.msg369267.html#msg369267)
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.
Vielleicht hilft dir HCS
http://forum.fhem.de/index.php/topic,14786.msg359978.html#msg359978
Gruß Billy
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.
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
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
*/
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"?
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.
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 ...
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
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.
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?
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
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
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?
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
36_KeyValueProtocol.pm
das macht doch gleich was her :)
folgendes habe ich bis jetzt nur kompiliert (kein Laufzeittest)
Include-Datei Sensors.h
#include <Arduino.h>
#ifndef _TEST1_h
#define _TEST1_h
// output keys as String
#define KEYS_AS_STRING 1
#define SENSOR_KEY_DELIMITER ' '
#define SENSOR_KEY_VALUE_DELIMITER ':'
#define SENSOR_VALUE_DELIMITER ','
#define SensorValueHeader(type, id) { ((String)"OK") + SENSOR_KEY_DELIMITER + type + SENSOR_KEY_DELIMITER + id }
#define SensorValue(key, value) { ((String)SENSOR_KEY_DELIMITER) + key + SENSOR_KEY_VALUE_DELIMITER + value }
// define strings
#ifdef KEYS_AS_STRING
#define SENSOR_TEMPERATURE_OUTSIDE F("TemperatureOutside")
#define SENSOR_TEMPERATURE_INSIDE F("TemperatureInside")
#define SENSOR_PRESSURE F("Pressure")
// define numbers
#else
#define SENSOR_TEMPERATURE_OUTSIDE 1
#define SENSOR_TEMPERATURE_INSIDE 2
#define SENSOR_PRESSURE 3
#endif
#endif // _TEST1_h
im Sketch
#define PROGNAME F("DAVIS")
#define PROGVERSION "0.1"
Serial.print(SensorValueHeader(PROGNAME, 0));
Serial.print(SensorValue(SENSOR_TEMPERATURE_OUTSIDE, 59.4));
Zitat von: justme1968 am 17 November 2015, 14:23:48
das macht doch gleich was her :)
Definitiv ... :)
Kannst Du schon mal die default MatchList und Clients vom JeeLink Modul erweitern?
"7:KeyValueProtocol" => "^OK\\sVALUES\\s"
erledigt.
Zitat von: justme1968 am 17 November 2015, 16:51:52
erledigt.
Mist, bist schneller als ich, muss aber auch in paar Zeilen mehr produzieren :)
Aber mit etwas Glück werfe ich heute Abend eine erste (Spar)Version von 36_KeyValueProtocol.pm in den Ring.
Gegen die kann habeIchVergessen dann anfangen zu implementieren.
so habe jetzt den Laufzeit Test durch und den Sketch angepasst.
OK VALUES DAVIS 0 Channel:1 RSSI:-81 Battery:ok WindSpeed:1 WindDirection:-36 Rain:39
OK VALUES DAVIS 0 Channel:3 RSSI:-81 Battery:ok WindSpeed:0 WindDirection:-36 TemperatureOutside:55.90
OK VALUES DAVIS 0 Channel:0 RSSI:-81 Battery:ok WindSpeed:0 WindDirection:-36 Rain:39
OK VALUES DAVIS 0 Channel:1 RSSI:-81 Battery:ok WindSpeed:0 WindDirection:-36 RainSecs:-1
OK VALUES DAVIS 0 Channel:3 RSSI:-78 Battery:ok WindSpeed:0 WindDirection:-36
OK VALUES DAVIS 0 Channel:0 RSSI:-79 Battery:ok WindSpeed:0 WindDirection:-36 RainSecs:-1
OK VALUES DAVIS 0 Channel:1 RSSI:-79 Battery:ok WindSpeed:0 WindDirection:-38 TemperatureOutside:55.90
OK VALUES DAVIS 0 Channel:0 RSSI:-79 Battery:ok WindSpeed:0 WindDirection:-38 TemperatureOutside:55.90
OK VALUES DAVIS 0 Channel:4 RSSI:-79 Battery:ok WindSpeed:0 WindDirection:-38 TemperatureOutside:55.90
OK VALUES DAVIS 0 Channel:0 RSSI:-81 Battery:ok WindSpeed:0 WindDirection:-38 VueCAP:7.02
OK VALUES DAVIS 0 Channel:3 RSSI:-81 Battery:ok WindSpeed:0 WindDirection:-38 TemperatureOutside:55.90
OK VALUES DAVIS 0 Channel:4 RSSI:-79 Battery:ok WindSpeed:0 WindDirection:-38 VueSolar:4
OK VALUES DAVIS 0 Channel:0 RSSI:-80 Battery:ok WindSpeed:0 WindDirection:-38 Rain:39
OK VALUES DAVIS 0 Channel:1 RSSI:-80 Battery:ok WindSpeed:0 WindDirection:-38 RainSecs:-1
OK VALUES DAVIS 0 Channel:3 RSSI:-79 Battery:ok WindSpeed:0 WindDirection:-38
OK VALUES DAVIS 0 Channel:4 RSSI:-81 Battery:ok WindSpeed:0 WindDirection:-38 Rain:39
OK VALUES DAVIS 0 Channel:0 RSSI:-82 Battery:ok WindSpeed:0 WindDirection:-38 RainSecs:-1
OK VALUES DAVIS 0 Channel:1 RSSI:-81 Battery:ok WindSpeed:0 WindDirection:-38 TemperatureOutside:55.90
OK VALUES DAVIS 0 253:0 252:-79 254:ok 6:0 7:63 15:7.08
OK VALUES DAVIS 0 253:3 252:-79 254:ok 6:0 7:-31 1:55.90
OK VALUES DAVIS 0 253:0 252:-79 254:ok 6:0 7:-31 10:39
OK VALUES DAVIS 0 253:1 252:-79 254:ok 6:0 7:-31
OK VALUES DAVIS 0 253:3 252:-79 254:ok 6:1 7:-30
OK VALUES DAVIS 0 253:4 252:-79 254:ok 6:0 7:-30 10:39
OK VALUES DAVIS 0 253:0 252:-79 254:ok 6:0 7:-31
OK VALUES DAVIS 0 253:1 252:-80 254:ok 6:0 7:40 1:55.90
OK VALUES DAVIS 0 253:3 252:-80 254:ok 6:0 7:41 10:39
Ausgabe mit Text oder ID kann über define im Header-File (s. Anhang) eingestellt werden.
Im Sketch sieht das dann so aus:
case VP2P_HUMIDITY:
val = ((packet[4] >> 4) << 8 | packet[3]) / 10; // 0 -> no sensor
Serial.print(SensorDataValue(SENSOR_HUMIDITY, (float)val));
break;
case VP2P_WINDGUST:
Serial.print(SensorDataValue(SENSOR_WIND_GUST, packet[3]));
if (packet[3] != 0)
Serial.print(SensorDataValue(SENSOR_WIND_GUST_REF, (packet[5] & 0xf0 >> 4)));
break;
case VP2P_SOIL_LEAF:
// no public documentation of the packet type yet
Serial.print(SensorDataValue(SENSOR_SOIL_LEAF, -1));
break;
case VUEP_VCAP:
val = (packet[3] << 2) | (packet[4] & 0xc0) >> 6;
Serial.print(SensorDataValue(SENSOR_VCAP, (float)(val / 100.0)));
break;
case VUEP_VSOLAR:
val = (packet[3] << 2) | (packet[4] & 0xc0) >> 6;
Serial.print(SensorDataValue(SENSOR_VSOLAR, val));
Zitat von: habeIchVergessen am 17 November 2015, 18:20:12
OK VALUES DAVIS 0 Channel:3 RSSI:-81 Battery:ok WindSpeed:0 WindDirection:-36 TemperatureOutside:55.90
Wohnst Du im Death Valley? ;D
Du musst die einzelnen Readings mit Komma trennen:
OK VALUES DAVIS 0 Channel:3, RSSI:-81, Battery:ok, WindSpeed:0, WindDirection:-36, TemperatureOutside:55.90
kein Problem. Ich hätte das Komma für Wertelisten zurückgehalten. z.B.
OK VALUES DAVIS 0 Channel:1 RSSI:-75 Battery:ok WindSpeed:3 WindDirection:-58,-60
OK VALUES DAVIS 0 Channel:1, RSSI:-75, Battery:ok, WindSpeed:3, WindDirection:-58
OK VALUES DAVIS 0 Channel:2, RSSI:-76, Battery:ok, WindSpeed:2, WindDirection:-58, Rain:42
OK VALUES DAVIS 0 Channel:3, RSSI:-76, Battery:ok, WindSpeed:1, WindDirection:-58, RainSecs:31
OK VALUES DAVIS 0 Channel:4, RSSI:-75, Battery:ok, WindSpeed:1, WindDirection:-58, TemperatureOutside:55.60
OK VALUES DAVIS 0 Channel:0, RSSI:-75, Battery:ok, WindSpeed:0, WindDirection:-58, WindGust:6, WindGustRef:9
OK VALUES DAVIS 0 Channel:1, RSSI:-75, Battery:ok, WindSpeed:0, WindDirection:-57, Rain:42
OK VALUES DAVIS 0 Channel:2, RSSI:-75, Battery:ok, WindSpeed:0, WindDirection:-57, RainSecs:31
OK VALUES DAVIS 0 Channel:3, RSSI:-75, Battery:ok, WindSpeed:0, WindDirection:-57, TemperatureOutside:55.60
OK VALUES DAVIS 0 Channel:4, RSSI:-76, Battery:ok, WindSpeed:0, WindDirection:-57, Humidity:90.00
anbei die aktualisierte Header-Datei.
Sketch muss jetzt wissen, ob ein Trennzeichen geschrieben werden muss.
Serial.print(SensorDataHeader(PROGNAME, id));
Serial.print(SensorDataValue(SENSOR_CHANNEL, rd->channel));
Serial.print(SensorDataValueDelimiter(SENSOR_RSSI, -rd->rssi));
Serial.print(SensorDataValueDelimiter(SENSOR_BATTERY_STATUS, (char*)(packet[0] & 0x8 ? "err" : "ok")));
So, hier der erste Anlauf.
Testen kann man es z.B. mit
set myJeeLink parse OK VALUES DAVIS 0 Channel:3, RSSI:-81, Battery:ok, WindSpeed:0, WindDirection:-36, TemperatureOutside:55.90
Wenn man das zwei mal absetzt, bekommt man per AutoCreate das device und ein FileLog und sollte dann auch Werte sehen.
Das Modul kann manuell so definiert werden:
define myDavis KeyValueProtocol DAVIS 0
define <Name> KeyValueProtocol <Type> <ID>
wobei <Type> und <ID> den ersten beiden Angaben entspricht, was der Sketch sendet.
Aktuell noch ohne die Dictionary Umsetzung.
Da ist mir aber ein Gedanke dazu gekommen: evtl. wäre es praktisch, wenn das Dictionary nicht vom Sketch sondern vom Anwender in einem Attribut definiert wird. Dann kann jeder selbst bestimmen, wie die Readings heißen sollen und ist nicht den Sketch-Ersteller ausgeliefert.
Der Sketch könnte eine noch verständliche Kurzform senden (oder alternativ auch die Langversion):
OK VALUES DAVIS 0 C:3 R:-81 B:ok WS:0 WD:-36 TO:55.90
Aus beidem (kurz oder lang) könnte der Anwender dann die Readings machen, die er wirklich will, evtl. sogar so, dass dann nur die entstehen, für die er ein Mapping gemacht hat.
Er würde also in diesem Beispiel in das Attribut "Readings" das hier "WS:WindSpeed,WD:WindDirection,TO:Temperature" eintragen und nur die drei readings bekommen.
noch ein Vorschlag
zu Analysezwecken
OK DIAG DAVIS PacketRawData:37-a5-65-ce-49-22-b9-c3-04-f7
und für ein Discover von Device-IDs
OK DISCOVER DAVIS 0 RSSI:-75
Zitat von: habeIchVergessen am 17 November 2015, 23:53:33
zu Analysezwecken
OK DIAG DAVIS PacketRawData:37-a5-65-ce-49-22-b9-c3-04-f7
Sende doch einfach "OK VALUES DavisDiag 0 PacketRawData:37-a5-65-ce-49-22-b9-c3-04-f7"
Zitat von: habeIchVergessen am 17 November 2015, 23:53:33
und für ein Discover von Device-IDs
OK DISCOVER DAVIS 0 RSSI:-75
Sinngemäß
Zitat von: HCS am 17 November 2015, 23:49:20
Der Sketch könnte eine noch verständliche Kurzform senden (oder alternativ auch die Langversion):
warum nicht gleich die Version mit den IDs, die für alle in der Header-Datei als Referenz abgelegt sind? Oder durch ein XSLT/oder noch nicht beschriebene Alternative den Perl- und Sketch-Code (Header-Datei) generieren lassen?
Dann müssen nur die Kompilate zusammen passen.
Kann bei der Initialisierung eines Modules so eine Mapping-Liste von außen übergeben werden, die dann das generierte Default-Mapping (s.o.) ersetzt?
Noch eine Frage zur Initialisierung. Bei Davis gibt es nur 8 Device-IDs. Zusätzlich wird ein Frequenz-Hopping genutzt, das für jede ID unterschiedlich lange Sendeintervalle hat. Somit muss ständig berechnet werden, auf welcher Frequenz das nächste Gerät senden wird. Deshalb ist der Sketch zur Zeit so aufgebaut, dass er über die serielle Eingabe konfiguriert werden muss (ID und Device-Typ). Gibt es dafür auch Mechanismen in FHEM?
Das ist der erste Anlauf, der nun Stück für Stück ausgebaut wird.
Perl oder Sketch Code generieren und verwenden ist mir definitiv zu speziell weil nur für diesen Anwendungsfall hier.
Der Sketch könnte das Mapping senden (optional, wenn er will) so dass das Attribut erst mal automatisch entsteht, und der Anwender es, wenn er will, dann anpassen kann.
Oder mal so formuliert: ich will keine Speziallösung für Davis bauen sondern eine universelle, die auch für das LaCrosseGateway und andere Sketches funktioniert, ohne denen neue Zwänge aufzuerlegen.
Zitat von: habeIchVergessen am 18 November 2015, 00:06:57Deshalb ist der Sketch zur Zeit so aufgebaut, dass er über die serielle Eingabe konfiguriert werden muss (ID und Device-Typ). Gibt es dafür auch Mechanismen in FHEM?
Ja, die InitCommands im JeeLink Modul. Die werden nach dem Öffnen der Schnittstelle an den Sketch gesendet.
Siehe LaCrosse Sketch.
kurze Rückfrage : brauche ich dann die komplette Wetterstation oder reicht mir die Ausseneinheit?
Zitat von: JoeALLb am 18 November 2015, 07:10:44
kurze Rückfrage : brauche ich dann die komplette Wetterstation oder reicht mir die Ausseneinheit?
ich habe nur die Vantage Vue Außeneinheit.
@HCS:
ich habe ein kurzes Beispiel zum bessern Verständnis zusammen gebaut.
#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.
Zitat von: habeIchVergessen am 18 November 2015, 09:11:48
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:
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
OK VALUES LGW 25e38 UpTime:125655,Status:connected,USB-Voltage:5.01,ReceivedPackets:1250erweitere, 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:
OK DICTIONARY 1=Temperature,2=Humidity,3=WindSpeedDas 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.
Zitat von: habeIchVergessen am 18 November 2015, 09:11:48
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.
Zitat von: HCS am 18 November 2015, 09:59:48
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).
Zitat von: HCS am 18 November 2015, 09:59:48
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!
Zitat von: HCS am 18 November 2015, 09:59:48
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 0
hierChannel: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>).
Zitat von: HCS am 18 November 2015, 09:59:48
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!
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.
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.
Zitat von: habeIchVergessen am 18 November 2015, 13:29:01Trotzdem 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 ;D ;D
So, nun nun ernsthaft:
Zitat von: habeIchVergessen am 18 November 2015, 13:29:01
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:
{ "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
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!!
Zitat von: JoeALLb am 18 November 2015, 14:28:27Also ich wäre absoluter Fan von "36_KeyValueProtocol"
Bin auch ein Fan davon :)
Zitat von: JoeALLb am 18 November 2015, 14:28:27... 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.
Zitat von: JoeALLb am 18 November 2015, 14:28:27Wenn 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.
Wie sieht es mit der anderen Richtung aus, kann man Einstellungen/Parameter für den Sketch auch darüber generalisieren?
Zitat von: JoeALLb am 18 November 2015, 15:32:46
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.
@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.
hab mir die Zeit genommen und 36_KeyValueProtocol.pm und 36_JeeLink.pm in meine Installation kopiert.
Hier die Ausgabe von list KeyValue.*
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.
Zitat von: habeIchVergessen am 18 November 2015, 20:28:57...
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:ReadyErgibt:...
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
Das "Mapping" Attribut wäre dann auch drin.
Beispiel:
Mapping:
attr KeyValueProtocol_LGW_12345 Mapping U=UpTime,S=SSID,T=LastDateReception,M=Mode,O=OTA-State
Eingehende Daten
OK VALUES LGW 12345 U:2345678, S:MyCoolNetwork,T:2015-11-17 13:39:14,M:OK,Connected,Cool,O:Ready
Ergebnis:
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
in einem Macro können Parameter mittels ## um ein Suffix ergänzt werden
#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).
Mapping scheint nicht zu funktionieren
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.
Du musst es auch mit = angeben
a=Column1,b=Column2,c=Column3
Danke
Sensor-Definition auf enum geändert. Nach meinem Dafürhalten sehr übersichtlich und leicht generierbar.
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?
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
noch ein perl Brocken, um gegen ein Default-Mapping Liste zu prüfen:
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
# 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
Zitat von: justme1968 am 20 November 2015, 20:07:25
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?
Zitat von: habeIchVergessen am 20 November 2015, 19:57:20
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.
Zitat von: habeIchVergessen am 20 November 2015, 20:15:35
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.
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.
@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.
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.
Zitat von: justme1968 am 20 November 2015, 20:54:17
...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 :o
Zitat von: justme1968 am 20 November 2015, 20:54:17
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
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...
Zitat von: habeIchVergessen am 20 November 2015, 19:57:20
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.
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.
Zitat von: habeIchVergessen am 21 November 2015, 00:01:35
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?
Zitat von: habeIchVergessen am 21 November 2015, 00:01:35
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.
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
Zitat von: justme1968 am 21 November 2015, 13:10:13
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.
Zitat von: justme1968 am 21 November 2015, 13:10:13
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.
Zitat von: justme1968 am 21 November 2015, 13:10:13
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 ;D
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.
@HCS: folgende Nachricht kann nicht richtig geparst werden
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. |).
Warum?
Also ich meine damit warum ausgerechnet die pipe?
{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.
Zitat von: justme1968 am 21 November 2015, 15:40:12
{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.
kannst du mal bitte schauen warum das newline verloren geht und ob das besser funktioniert:
if( $dmsg =~ /^INIT / ) {
$hash->{initMessages} .= "\n" if( $hash->{initMessages} );
$hash->{initMessages} .= $dmsg;
return;
}
Zitat von: justme1968 am 21 November 2015, 15:47:36
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.
ja. das ist die ursache. das set raw muss eigentlich ein newline anhängen
Zitat von: HCS am 21 November 2015, 15:29:54
Also ich meine damit warum ausgerechnet die pipe?
kann auch ein & sein (wie bei HTTP). hauptsache es ist definiert.
ich denke in den aller meisten fällen kommen wir mit einem default von : und , hin. : um den key von value zu trennen und , um einzelne reading zu trennen.
mit der logik von HCS funktioniert das sogar wenn das , in einem wert auftaucht. das geht erst schief wenn auch das zweite zeichen im wert auftauchen darf.
wir können jetzt lange über einen anderen default diskutieren (z.b. = und ;) aber das ändert nichts daran das es probleme gib sobald beide zeichen auch im wert auftauchen dürfen.
es gibt zwei möglichkeiten das zu lösen: wir definieren wie man die beiden zeichen escapen kann oder wird erlauben das der sketch angeben kann welche beiden zeichen als trennzeichen verwendet werden.
- als teil der DICTIONARY nachricht
- oder in einer eigenen INIT SEPARATOR nachricht
INIT SEPARATOR wäre vermutlich das sauberstes und flexibelste. z.b. so: INIT SEPARATOR 1:= 2:;
gruss
andre
oder eben per regexp pattern festlegen, wie das Format sein soll.
[\s]{0,}(\w+)::([\w\-,][\w\-\s,:]*)(&.*|$)
(<Name>)::(<Wert>)(&<restliche Zeichenkette, die geparst wird>)
vor dem Namen beliebig viele Leerzeichen zulassen
Name besteht aus a-z A-Z 0-9 _
Trennzeichen (2 Byte) zwischen Name und Wert ist ::
Wert begint mindestens mit a-z A-Z 0-9 _ - , alle nachfolgenden Zeichen können a-z A-Z 0-9 _ - ' ' : sein
Trennzeichen (im Beispiel &) und die restliche Zeichenkette oder Zeilenende.
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
da & nicht in den Werten zugelassen ist, sollte es kein Problem geben.
Zitat von: justme1968 am 21 November 2015, 18:22:37
es gibt zwei möglichkeiten das zu lösen: wir definieren wie man die beiden zeichen escapen kann oder wird erlauben das der sketch angeben kann welche beiden zeichen als trennzeichen verwendet werden.
Darüber denke ich dann bei Gelegenheit mal nach, bin gerade mit den Nerven runter :o
Beim Testen ist mir aufgefallen, dass der JeeLink weder bei einem "set myJeeLink reset" noch bei einem Neustart einen Reset macht.
Anderen JeeLink genommen, genauso.
Auf dem Produktivsystem geschaut, da geht es.
Server neu gebootet, hilft nix.
Ewig gesucht, IODev wird geschlossen und wieder geöffnet, alles prima.
Ein blankes neues FEHM aufgespielt, ein JeeLink device angelegt, geht.
Das ursprüngliche FHEM wieder draufgespielt -> FUNKTIONIERT
Ich verstehe nur nicht, warum?
Egal, zu den newlines:
Da brauchen wir diese Variante:
if( $dmsg =~ /^INIT / ) {
$hash->{initMessages} .= "\n" if( $hash->{initMessages} );
$hash->{initMessages} .= $dmsg;
return;
}
An der rmsg, die JeeLink_Parse rein bekommt, sind nie linefeeds dran, bei keiner "OK ..." und auch bei sonst nichts.
Ich habe einen LaCrosse Sketch laufen, der eine Initialisierung schickt, das klappt so weit.
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 10
NAME myJeeLink
NR 20
PARTIAL
RAWMSG OK 9 41 1 4 184 60
STATE Initialized
TYPE JeeLink
initMessages INIT DICTIONARY U=UpTime,M=MessagesPerMinute,S:SSID
INIT TEST InitTest
model [LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:9579)] Die "OK VALUES JeeLink 01 U:25005,M:25,S:USB" laufen auch wunderbar in das per autcreate entstandene KeyValueProtocol_JeeLink_01 device.
Dem werde ich dann mal die initMessages aus den JeeLink internals beibringen.
hab es so eingecheckt.
gruss
andre
Zitat von: justme1968 am 21 November 2015, 18:22:37
ich denke in den aller meisten fällen kommen wir mit einem default von : und , hin. : um den key von value zu trennen und , um einzelne reading zu trennen.
mit der logik von HCS funktioniert das sogar wenn das , in einem wert auftaucht. das geht erst schief wenn auch das zweite zeichen im wert auftauchen darf.
Genau, und da stelle ich mir die Frage, ob das den ganzen Aufwand wert ist, mit noch mehr Initialisierung usw.
Das ist doch ein eher hypothetischer use case.
Das gegebene Beispiel
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:Readykann ein Sketch doch problemlos dadurch vermeiden, dass er es in zwei KVPs übermittelt.
LastReceiveTime1:2015-11-17 13:39:14
LastReceiveTime2:2015-11-18 13:33:14oder er in so einem Spezialfall das Komma vermeidet
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:ReadyIch bin dafür, das erst mal so zu lassen, wie es jetzt funktioniert und abzuwarten, ob es wirklich real world use cases geben wird, wo man damit nicht klar kommt. Dann kann man es immer noch erweitern.
das denke ich auch.
wir können höchstens überlegen = statt : zu verwenden.
Zitat von: justme1968 am 22 November 2015, 09:42:15
wir können höchstens überlegen = statt : zu verwenden.
Wäre auch OK, dann passt es auch zu "INIT DICTIONARY T=Temperature,H=Humidity"
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=ReadyIch baue es auf = um
hab mal ein Select über die Anzahl der Readings (WindSpeed) ausgeführt.
Wert|Anzahl
0.00|31249
1.61|3884
11.26|2
14.48|1
3.22|983
4.83|247
6.44|102
8.05|21
9.65|6
Können wir in 36_KeyValueProtocol einbauen, dass Readings nur aktualisiert werden, wenn sie sich geändert haben? Vorschlag:
if ($rhash->{READINGS}{$key}{VAL} ne $value) {
readingsBulkUpdate($rhash, $key, $value);
}
ggf. noch ein Attribut zum steuern dessen (nicht im Beispiel enthalten; bin schon zufrieden, dass das o.g. funktioniert).
für gibt es die event-on-change-reading und event-on-update-reading attribute.
gruss
andre
36_KeyValueProtocol.pm ist eingecheckt.
- Auf = umgebaut
- commandref erledigt
- verwendet initMessages vom JeeLink modul, das eigene Dictionary Attribut hat Vorrang
Dictionary geht bei mir nicht!?
fhem> list KeyValue.*
Internals:
CFGFN
DEF DAVIS 0
ID DAVIS_0
IODev
LASTInputDev davisJeeLink
MSGCNT 45
NAME KeyValueProtocol_DAVIS_0
NR 534
STATE Initialized
TYPE KeyValueProtocol
davisJeeLink_MSGCNT 45
davisJeeLink_RAWMSG OK VALUES DAVIS 0 20=3,22=-85,21=ok,4=0.00,5=-50,9=-1,
davisJeeLink_TIME 2015-11-22 19:45:15
model DAVIS
Readings:
2015-11-22 19:43:55 1 -1.67
2015-11-22 19:43:48 11 1
2015-11-22 19:43:37 12 6.74
2015-11-22 19:45:15 20 3
2015-11-22 19:45:15 21 ok
2015-11-22 19:45:15 22 -85
2015-11-22 19:45:10 3 96.00
2015-11-22 19:45:15 4 0.00
2015-11-22 19:45:15 5 -50
2015-11-22 19:43:17 6 0
2015-11-22 19:43:17 7 -1
2015-11-22 19:43:50 8 93
2015-11-22 19:45:15 9 -1
Attributes:
room KeyValueProtocol
fhem> list davisJeeLink
Internals:
CFGFN fhem_davis.cfg
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 6
NAME davisJeeLink
NR 144
PARTIAL
RAWMSG OK VALUES DAVIS 0 20=1,22=-86,21=ok,4=0.00,5=-50,1=-1.67,
STATE Initialized
TYPE JeeLink
davisJeeLink_MSGCNT 39522
davisJeeLink_TIME 2015-11-22 19:46:39
initMessages INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSecs,10=Solar,11=VoltageSolar,12=VoltageCapacity,13=SoilLeaf,20=Channel,21=Battery,22=RSSI,255=PacketDump,
model [DAVIS.0.1 (RFM69 b:2)]
Matchlist:
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:KeyValueProtocol ^OK\sVALUES\s
Readings:
2015-11-22 19:45:02 state opened
$key:
Battery:
Channel:
Humidity:
Rssi:
Rain:
Rainsecs:
Temperature:
Voltagecapacity:
Voltagesolar:
Winddirection:
Windspeed:
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 0,16s r
eine Idee, warum?
Zitat von: habeIchVergessen am 22 November 2015, 19:48:48
Dictionary geht bei mir nicht!?
...
eine Idee, warum?
Dein KeyValueProtocol_DAVIS_0 hat kein IODev (ist leer). Dann weiß das Modul nicht, wo es die initMessages hernehmen soll.
Setz mal das Attribut.
Damit in dem Internal was drin stehen kann, muss bestimmt ein autocreate erfolgen?
Es gibt ein Attribut in 36_KeyValueProtocol, das man setzen kann.
Ja, das Mapping Attribut.
Ich wollte wissen, ob im Internals IODev nur ein Wert erscheint, wenn die KeyValueProtocol-Instance per AutoCreate erstellt wurde. Ist das so?
Zitat von: habeIchVergessen am 22 November 2015, 22:13:23
Ja, das Mapping Attribut.
Und das IODev Attribut
Zitat von: habeIchVergessen am 22 November 2015, 22:13:23
Ich wollte wissen, ob im Internals IODev nur ein Wert erscheint, wenn die KeyValueProtocol-Instance per AutoCreate erstellt wurde. Ist das so?
Nein, ein
define KVPTest KeyValueProtocol TEST 1führt bei mir zu:
Internals:
CFGFN
DEF TEST 1
ID TEST_1
IODev myJeeLinkUSB
NAME KVPTest
NR 442
STATE Initialized
TYPE KeyValueProtocol
model TEST
Attributes:
IODev myJeeLinkUSB
hatte gerade das Device gelöscht und autocreate hat das hier angelegt
fhem> list Key.*
Internals:
CFGFN
DEF DAVIS 0
ID DAVIS_0
IODev
LASTInputDev davisJeeLink
MSGCNT 3
NAME KeyValueProtocol_DAVIS_0
NR 707
STATE Initialized
TYPE KeyValueProtocol
davisJeeLink_MSGCNT 3
davisJeeLink_RAWMSG OK VALUES DAVIS 0 Channel=3,RSSI=-81,Battery=ok,WindSpeed=0.00,WindDirection=-43,
davisJeeLink_TIME 2015-11-22 22:35:40
model DAVIS
CHANGETIME:
Helper:
Dblog:
Rainsecs:
Dbhistdatalog:
TIME 1448228134.91748
VALUE -1
Raintipcount:
Dbhistdatalog:
TIME 1448228132.34709
VALUE 93
Winddirection:
Dbhistdatalog:
TIME 1448228140.03193
VALUE -43
Windspeed:
Dbhistdatalog:
TIME 1448228140.03193
VALUE 0.00
Readings:
2015-11-22 22:35:40 Battery ok
2015-11-22 22:35:40 Channel 3
2015-11-22 22:35:40 RSSI -81
2015-11-22 22:35:34 RainSecs -1
2015-11-22 22:35:32 RainTipCount 93
2015-11-22 22:35:40 WindDirection -43
2015-11-22 22:35:40 WindSpeed 0.00
Attributes:
room KeyValueProtocol
Sorry, keine Ahnung, warum Du kein IODev bekommst. Evtl. hat ja justme1968 eine Idee.
Hast Du das IODev Attribut mal gesetzt und funktioniert das Mapping dann?
hab ich handisch gesetzt und jetzt funktioniert es. wäre nie auf die Idee gekommen ein "Internals" zu beschreiben.
ich bin erstmal sehr zufrieden mit euren Ergebnissen nach nur einer Woche Arbeit.
ggf. sollten noch die Sourcen für den Sketch irgendwo ablegt werden. Wer übernimmt das?
Zitat von: habeIchVergessen am 22 November 2015, 23:47:40
ggf. sollten noch die Sourcen für den Sketch irgendwo ablegt werden. Wer übernimmt das?
Mach ein 36_DavisVantage.zip in dem die Sourcen und das compilierte .hex drin sind, dann werfe ich es in trunk/fhem/contrib/arduino/ rein.
Zitat von: habeIchVergessen am 22 November 2015, 23:47:40
ich bin erstmal sehr zufrieden mit euren Ergebnissen nach nur einer Woche Arbeit.
War ja auch eine harte Woche ;D ;D
anbei die Sourcen für den Sketch
@habeIchVergessen
Würde damit diese AUSSENEINHEIT ISS 6357 DAVIS VUE problemlos laufen?
http://www.ebay.de/itm/like/380534956300?ul_noapp=true&chn=ps&lpid=106
Nur mal interessehalber.
Gruß Billy
hab bei Wetterladen.de gekauft.
auf das 868MHz Funkmodul sollte geachtet werden (also nicht die US/AU Version).
Ein JeeLink v3c (RFM69CW) ist erforderlich. RFM12B Funkchips reichen nicht!
Zitat von: habeIchVergessen am 23 November 2015, 19:53:33
anbei die Sourcen für den Sketch
Habe es eingecheckt.
@habeIchVergessen: Ideal wäre, wenn Du Deinen Beitrag #1 ganz oben überarbeiten und kurz beschreiben würdest, wozu es gut ist und wie man es verwendet.
Dann muss sich ein interessierter Anwender nicht durch die 97 Posts kämpfen, um herauszufinden, wie er es einsetzen kann.
Beschreibung unterstützer Sketch-Kommandos:
- Frequenz-Band auswählen <band>b (Es wird nur eine fest programmierte Liste von Frequenzen ausgewählt)
- 0 - US (915 MHz; 51 Einträge)
- 1 - AU (915 MHz; 51 Einträge)
- 2 - EU (868 MHz; 5 Einträge; default)
- Packet Dump <packet>p
- 0 - ausschalten (default)
- 1 - empfangene Pakete (inkl. CRC)
- 2 - verworfene Pakete
- 3 - alle Pakete
- Station konfigurieren <id>,<type>s
- id - Davis verwendet die IDs 0-7 (wird beim Einrichten des Sensors gewählt)
- type - Typ der Station
- 0 - Vantage Pro 2
- 1 - Temperatur
- 2 - Luftfeuchtigkeit
- 3 - Temperatur + Luftfeuchtigkeit
- 4 - Windmesser
- 5 - Regenmesser
- 6 - Leaf Station
- 7 - Soil Station
- 8 - Leaf + Soil Station
- 9 - SensorLink
- 10 - Station ausschalten
- 16 - Vantage Vue (im Testbetrieb)
- Empfang von Nachrichten steuern [enable]r
- 0 - auschalten
- 1 - einschalten (default)
- LED [enable]l
- 0 - auschalten (default)
- 1 - einschalten
- Version v
generelle Informationen zum Sketch:
Bevor Nachrichten für die konfigurierten Stationen empfangen werden, findet eine initiale Prüfung zum Vorhandensein dieser statt. Sofern eine Station nicht sendet, endet diese Phase nicht! Dies ist in der Arbeitsweise des Protokolls (Davis) begründet. Es wird zu einem bestimmten Zeitpunkt das Senden der Station X auf Frequenz Y (Eintrag aus Liste zu Band) erwartet. Mit zunehmender ID werden die Sendeabstände größer.
[aktualisiert 29.06.2016]
UserReadings werden als kommaseparierte Liste angegeben. Das Device VantageVue muss ggf. in den Beispielen angepasst werden.
Taupunkt (nicht exakt berechnet)
DewPoint:(Temperature.*|Humidity.*) { sprintf("%.2f", ReadingsVal("VantageVue", "Temperature", 0) - (100 - ReadingsVal("VantageVue", "Humidity", 99)) / 5.0);; }
gefühlte Temperature
WindChill:(WindSpeed.*|Temperature.*) { my $wc;; my $ws = (ReadingsVal("VantageVue", "WindSpeed", 0) ** 0.16);; my $temp = ReadingsVal("VantageVue", "Temperature", 0);; my $calc = 13.12 + 0.6215 * $temp - 11.37 * $ws + 0.3965 * $temp * $ws;; $wc = sprintf("%.2f", $calc) if ($calc < $temp);; }
Windgeschwindigkeit
WindForce:WindSpeed.* { my $wf;; my $ws=ReadingsVal("VantageVue", "WindSpeed", 0.00);; $ws=~s/(\d+)\.\d+/$1<1?0:($1<6?1:($1<12?2:($1<20?3:($1<29?4:($1<39?5:($1<50?6:($1<62?7:($1<75?8:($1<89?9:($1<103?10:($1<117?11:12)))))))))))/eg;; $wf=sprintf("%d", $ws);; }
Luftdruck
Pressure { ReadingsVal("YahooWetter", "pressure", "") }
Voraussetzung:
define YahooWetter Weather 638242 3600 de
attr YahooWetter event-on-update-reading pressure
intern verwendete Readings
_IsRaining { (ReadingsVal("VantageVue", "RainAmount", 0) > 0.0 ? 1 : 0) }
Reading für RainAmount
define VantageVue_RainAmount NOTIFY (VantageVue:RainTipCount.*) { my $dev="VantageVue";; my $ra=0;; my $rtc=ReadingsVal($dev, "RainTipCount", 0);; my $lrtc=ReadingsVal($dev, "_LastRainTipCount", "");; if ($lrtc eq "") { $lrtc=$rtc;; fhem "setreading $dev _LastRainTipCount " . $lrtc;; };; $ra=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * 0.2;; fhem "setreading $dev RainAmount " . $ra;; $lrtc=ReadingsVal($dev, "_LastRainTipCountTotal", "");; if ($lrtc eq "") { $lrtc=$rtc;; fhem "setreading $dev _LastRainTipCountTotal " . $lrtc;; };; $ra=ReadingsVal($dev, "RainAmountTotal", 0);; $ra+=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * 0.2;; fhem "setreading $dev RainAmountTotal " . $ra;; fhem "setreading $dev _LastRainTipCountTotal " . $rtc;; }
Regenmenge (bei mir hat der Löffel 0.2 mm => * 0.2; ggf. anpassen)
Reading für RainAmount (inkl. alte Werte aus DbLog lesen)
define VantageVue_RainAmount NOTIFY (VantageVue:RainTipCount.*) { my $spoon=0.2;; my $db="dbHistDataLog";; my $dev="VantageVue";; my $rtcName="RainTipCount";; my $raName="RainAmount";; my $ra=0;; my $dbrtc;; my $rtc=ReadingsVal($dev, $rtcName, 0);; my $lrtc=ReadingsVal($dev, "_Last${rtcName}", "");; if ($lrtc eq "") { $dbrtc=fhem("get $db ReadingsVal $dev $rtcName -1 ") if (defined($db));; $lrtc=($dbrtc != -1 ? $dbrtc : $rtc);; Log(3, "VantageVue_RainAmount: $dbrtc $lrtc");; fhem "setreading $dev _Last${rtcName} $lrtc";; };; $ra=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * $spoon;; fhem "setreading $dev $raName $ra";; $lrtc=ReadingsVal($dev, "_Last${rtcName}Total", "");; if ($lrtc eq "") { $dbrtc=fhem("get $db ReadingsVal $dev $rtcName -1 ") if (defined($db));; $lrtc=($dbrtc != -1 ? $dbrtc : $rtc);; Log(3, "VantageVue_RainAmount: $dbrtc $lrtc");; fhem "setreading $dev _Last" . $rtcName . "Total " . $lrtc;; };; $ra=ReadingsVal($dev, "RainAmountTotal", "");; $ra=fhem("get $db ReadingsVal $dev ${raName}Total -1 ") if ($ra eq "" && defined($db));; $ra+=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * $spoon;; fhem "setreading $dev ${raName}Total " . $ra;; fhem "setreading $dev _Last${rtcName}Total " . $rtc;; }
nach 15 min. _LastRainTipCount mit RainTipCount synchronisieren
define VantageVue_RainCheck at +*00:01 { my $dev="VantageVue";; my $ra=ReadingsVal($dev, "RainAmount", 0);; if ($ra > 0 && time_str2num(ReadingsTimestamp($dev, "RainAmount", "")) < time() - 900) { my $rtc=ReadingsVal($dev, "RainTipCount", 0);; fhem("setreading $dev _LastRainTipCount $rtc");; fhem("setreading $dev RainAmount 0");; };; }
Grafiken
# temp log
define VantageVue_Temp SVG dbHistDataLog:davis_temp:HISTORY
attr VantageVue_Temp label "Außen-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr VantageVue_Temp plotfunction VantageVue
attr VantageVue_Temp room EG
attr VantageVue_Temp sortby 2
# wind log
define VantageVue_Wind SVG dbHistDataLog:davis_wind:HISTORY
attr VantageVue_Wind label "Windgeschwindigkeit Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr VantageVue_Wind plotfunction VantageVue
attr VantageVue_Wind room EG
attr VantageVue_Wind sortby 3
attr VantageVue_Wind fixedrange hour
# rain log
define VantageVue_Rain SVG dbHistDataLog:davis_rain:HISTORY
attr VantageVue_Rain label "Regen pro 15 min. Max $data{max1}"
attr VantageVue_Rain plotfunction VantageVue
attr VantageVue_Rain room EG
attr VantageVue_Rain sortby 4
Hallo,
so ich habe nun dank habichvergessen meine Vantage Pro 2 mit externen Sender für den Windmesser ordnungsgemäß einrichten können.
Wichtig in diesen Fall ist, daß beide eine unterschiedliche Device ID zugewiesen bekommen. In meinen Fall hat die Vantage Pro ID=1 und der Windmesser ID=0.
Somit ergibt sich ein attr VantagePro initCommands 0,4s 1,0s r für den Jeelink. VantagePro ist in diesen Fall der Name des Jeelink.
Da es ja nun 2 Devices gibt. Bei mir einmal "Vantage_Pro" und für den Wind "Vantage_Wind". Um die nun readings vom "Vantage_Wind" im "Vantage_Pro" anzeigen, zu lassen, habe ich ein Userreadings für den "VantagePro" eingetragen.
attr Vantage_Pro userReadings WindDirection { ReadingsVal("Vantage_Wind", "WindDirection", 0) },WindSpeed { ReadingsVal("Vantage_Wind", "WindSpeed", 0) },_LastRainTipCount:InternalUseOnly { my $lrtc=ReadingsVal("Vantage_Pro", "_LastRainTipCount", -1);; $lrtc=ReadingsVal("Vantage_Pro", "RainTipCount", 0) if ($lrtc==-1);; },_IsRaining { (ReadingsVal("Vantage_Pro", "RainAmount", 0) > 0.0 ? 1 : 0) },RainAmount { my $ra=0;; my $rtc = ReadingsVal("Vantage_Pro", "RainTipCount", 0);; my $lrtc = ReadingsVal("Vantage_Pro", "_LastRainTipCount", -1);; $ra=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * 0.2 if($lrtc != -1);; },WindChill:(WindSpeed|Temperature) { my $wc;; my $ws = (ReadingsVal("Vantage_Pro", "WindSpeed", 0) ** 0.16);; my $temp = ReadingsVal("Vantage_Pro", "Temperature", 0);; my $calc = 13.12 + 0.6215 * $temp - 11.37 * $ws + 0.3965 * $temp * $ws;; $wc = sprintf("%.2f", $calc) if ($calc < $temp);; },WindForce:WindSpeed { my $wf;; my $ws=ReadingsVal("Vantage_Pro", "WindSpeed", 0.00);; $ws=~s/(\d+)\.\d+/$1<1?0:($1<6?1:($1<12?2:($1<20?3:($1<29?4:($1<39?5:($1<50?6:($1<62?7:($1<75?8:($1<89?9:($1<103?10:($1<117?11:12)))))))))))/eg;; $wf=sprintf("%d", $ws);; }
Des weiteren habe ich noch die UserReadings von habichvergessen eingepflegt.
Vielleicht hilft das den ein oder anderen weiter.
Vielen Dank nochmal an habichvergessen für den super Support.
Viele Grüße
Christian
Firmware Version 0.2 im Anhang.
@HCS: kannst du bitte die Datei einchecken.
v0.3 - Bugfix Berechnung WindDirection
@Dippy98: bitte testen
@habeIchVergessen: kannst auch developer Status beantragen, dann kannst Du es selbst einchecken ;)
Zitat von: habeIchVergessen am 06 Dezember 2015, 18:44:43
v0.3 - Bugfix Berechnung WindDirection
@Dippy98: bitte testen
funktioniert jetzt bestens mit der Vantage Pro 2.
Vielen Dank
Zitat von: Dippy98 am 04 Dezember 2015, 18:48:08
...,RainAmount { my $ra=0;; my $rtc = ReadingsVal("Vantage_Pro", "RainTipCount", 0);; my $lrtc = ReadingsVal("Vantage_Pro", "_LastRainTipCount", -1);; $ra=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * 0.2 if($lrtc != -1);; },...
änder mal
my $lrtc = ReadingsVal("Vantage_Pro", "_LastRainTipCount", -1);; $ra=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * 0.2 if($lrtc != -1);;
in
my $lrtc = ReadingsVal("Vantage_Pro", "_LastRainTipCount", "");; $ra=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * 0.2 if($lrtc ne "");;
Zitat von: habeIchVergessen am 06 Dezember 2015, 22:14:45
änder mal
my $lrtc = ReadingsVal("Vantage_Pro", "_LastRainTipCount", -1);; $ra=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * 0.2 if($lrtc != -1);;
in
my $lrtc = ReadingsVal("Vantage_Pro", "_LastRainTipCount", "");; $ra=($rtc + ($lrtc > $rtc ? 0x80 : 0x00) - $lrtc) * 0.2 if($lrtc ne "");;
Funktioniert leider immernoch nicht. :(
v0.4 - Bugfix Ausgabe BMP180 (cut&paste Fehler vom LaCrosse-Sketch)
muss das eigentlich ein eigener Sketch bleiben oder könnte man den in den LaCrosse - Sketch integrieren? Ggf. per toggle? Ich hab schon 2 Jeelinks und eigentlich keinen usb Port mehr frei ;-)
Zitat von: habeIchVergessen am 11 Dezember 2015, 14:32:16
v0.4 - Bugfix Ausgabe BMP180 (cut&paste Fehler vom LaCrosse-Sketch)
Das werde ich heute gleich mal probieren.
Zitat von: JoeALLb am 12 Dezember 2015, 06:50:05
muss das eigentlich ein eigener Sketch bleiben oder könnte man den in den LaCrosse - Sketch integrieren? Ggf. per toggle? Ich hab schon 2 Jeelinks und eigentlich keinen usb Port mehr frei ;-)
Davis benutzt ein Frequenz-Hopping und erwartet zu einer bestimmten Zeit das Senden auf einer bestimmten Frequenz. Somit sehe ich wenig bis keine Möglichkeit, dass das Funkmodul mit einer anderen Logik geteilt werden kann. Außerdem ist der LaCrosse-Sketch am Limit bzgl. des freien Programmspeichers auf einem JeeLink.
Ein NodeMCU wäre ggf. eine Alternative (mehr Speicher, eh schon mit bis zu 3 Funkmodulen geplant, WLAN als Übertragungsmedium).
Firmware v0.5 - Bugfix RFM Detection + Nano-Support
Hi habichvergessen,
so ich habe mal die Bilder des Jeelink mit Luftdrucksensor hochgeladen.
Wenn du eine bessere Auflösung, oder detaillierte Bilder brauchst, gebe mir kurz Bescheid.
(http://www.fotos-hochladen.net/uploads/img1270w4yzfq51kj.jpg)
(http://www.fotos-hochladen.net/uploads/img1271b7x29z6mn0.jpg)
Viele Grüße
Dippy98
sieht so aus, als wäre DIO0 (Bild 1) nicht mit dem Nano verbunden. Damit werden nie Daten vom Radio empfangen.
Eine Großaufnahme vom RFM wäre toll (Schrift muss lesbar sein).
Mache ich dir morgen.
Zitat von: habeIchVergessen am 19 Dezember 2015, 11:08:42
sieht so aus, als wäre DIO0 (Bild 1) nicht mit dem Nano verbunden. Damit werden nie Daten vom Radio empfangen.
Eine Großaufnahme noch RFM wäre toll (Schrift muss lesbar sein).
(http://www.fotos-hochladen.net/uploads/image8bmyns6ro5.jpg)
So ok?
sieht gut aus! SuperJee funktioniert also mit v0.5.
Hast du den RFM69 explizit angefordert?
Meinst du bei der Bestellung? Da war es mehr Zufall. Aber ich denke wenn man bei Robin bestellt, kann man auch den Wunsch nach einem RFM69 äußern.
Hallo,
ich habe mir einen JeeLink Nachbau zusammengelötet aus Arduino nano (China mit FTDI-Chip) + RFM69CW (Pollin) und wollte darauf die DAVIS Vantage Firmeware verwenden. Das funktioniert leider nicht.
Ich dachte erst, der JeeLink Nachbau funktioniert irgend wie nicht, aber nachdem ich die LaCrosse Firmeware geflasht habve läuft der JeeLink Nachbau tadellos und empfängt Signale von einem LaCrosse Außentemperaturfühler.
Mit der DavisVantage Firmeware wird noch nicht einmal der RF-Type ausgelesen. Sieht dann wie im beigefügten Screenshot aus. Ich habe schon mot dem Oszi gemessen und vermute, dass es am SPI Interface liegt, bzw. der PIN-Zuordnung.
Wenn ich das beim Überfliegen richtig gesehen habe, wird das SPI-Interface im LaCrosse Sketch anders angesteuert, als im DavisVantage-Sketch.
Hat schon jemand Erfahrung mit dem JeeLink Nachbau auf Basis nano + RFM69CW im Zusammenhang mit dem DV-Sketch. In der Diskussion weiter oben, wird doch auch ein nano verwendet.
Danke für einen Tip
Viele Grüße
Wolfgang
Hallo Wolfgang,
Also mein Arduino nano mit RFM69 und BMP180 läuft tadellos. Sowie der Lacrosse Sketch als auch der Vantage Sketch.
Viele Grüße
Christian
LaCrosse unterstützt 2 RFM Chips. MOSI, MISO und SCK sind für jedes RFM-Modul gleich. Nur NSS/CS ist unterschiedlich.
Entspricht deine Aufbau dem u.g. Schema?
RFM Nano Pin
NSS/CS D10
MOSI D11
MISO D12
SCK D13
DIO0 D2
Was steht in model vom JeeLink, wenn der LaCrosse-Sketch läuft?
Hallo,
erst einmal Danke für die schnelle Antwort. Den Screenshot für den JeeLink mit LaCross Sketch habe ich beigefügt.
Den Davis Vantage Sketch habe ich selbst in der Arduino IDE compiliert und den hex-File dann über den RPI mit avrdude geflasht. Der Log sieht auch gut aus.
Wenn ich das richtig gesehen habe, erfolgt die Pin-Zuordnung zumindest für SPI_CS und IRQ in dem File Vantage.h (hier Ausschnitt):
#ifndef VANTAGE_h
#define VANTAGE_h
#include <Arduino.h> //assumes Arduino IDE v1.0 or greater
//#define _DEBUG 1 // enable debug per compile
// Davis specific
#define DAVIS_PACKET_LEN 10 // ISS has fixed packet lengths of eight bytes, including CRC and trailing repeater info
#define SPI_CS 10 // SS is the SPI slave select pin, for instance D10 on atmega328
#define RF69_IRQ_PIN 2 // INT0 on AVRs should be connected to DIO0 (ex on Atmega328 it's D2)
#define CSMA_LIMIT -90 // upper RX signal sensitivity threshold in dBm for carrier sense access
#define RF69_MODE_SLEEP 0 // XTAL OFF
#define RF69_MODE_STANDBY 1 // XTAL ON
#define RF69_MODE_SYNTH 2 // PLL ON
#define RF69_MODE_RX 3 // RX MODE
#define RF69_MODE_TX 4 // TX MODE
Was mich gewundert hat war, dass der Wert für SPI_CS mit SS anstell der 10 vorbelegt war. Wie wurde der in dem 36_DavisVantage_v0.5.zip im Firmware-Verzeichnis enthaltene 36_DavisVantage.hex erzeugt?
Der Aufbau entspricht dem Schema, wie im Beitrag von habeichvergessen oben. Sonst würde aus meiner Sicht auch der LaCrosse Sketch nicht funktionieren.
Viele Grüße
Wolfgang
Hallo,
ich habe jetzt noch etwas gemessen. Der LaCrosse Sketch verwendet wohl 'Software SPI', d.h. die SPI_CLK Impules usw. werden durch setzen der Ports mit low und high erzeugt. Eine SPI_CLK Periode beträgt ca. 12us.
Das DavisVantage Sketch verwendet 'Hardware SPI'. Zunächst habe ich mal die SPI Clock Frequenz auf SPI_CLOCK_DIV32 gesetzt. Leider finde ich in keinem Datenblatt die Spezifikation für die min. Clock Periode des RFM69.
Die SPI_CS Zustände im DavisVantage Sketch passen irgend wie nicht zu den Clock Impulsen. Normalerweise geht der SPI_CS kurz vor dem ersten SPI_CLK auf low und nachdem das Byte/Word gesendet wurde wieder auf high. Das kann ich so aber nicht messen.
Warum ist in RFMxx.cpp die Funktion RFMxx::select() und RFMxx::unselect() definiert, die aber nirgends aufgerufen wird?
Editiert: Oh, habe die Aufrufe von select() und unselect() doch gefunden ;-)
Irgend wie meine ich, hängt mein Problem mit dem SPI-Interface zusammen.
Viele Grüße
Wolfgang
DIO0 ist auch verdrahtet? Kannst du ein Screenshot vom JeeLink posten? (ist erst interessant, wenn der RFM erkannt wurde!)
SS wird in pins_arduino.h (verschiedene Varianten unter hardware\arduino\avr\variants) definiert. Abhängig vom ausgewählten Board wird beim Compile automatisch der richtige GPIO gewählt. Welche Einstellungen verwendest du in der IDE? Welche Version der IDE?
Die DavisVantage.zip-Datei enthält die Sourcen, aus denen das hex-File generiert wurde.
DIO0 ist auch verdrahtet. Habe zur Sicherheit auch einen Pull-up hinzugefügt.
Wenn Du mit Screenshot des JeeLink das Schaltbild gemeint hast, ist es beigefügt.
Hallo,
ich habe den Fehler gefunden. In RFMxxx.cpp fehlt ein unselect(); gleich nach dem Umschalten des SPI_CS auf OUTPUT. Der SPI_CS Pin lag deshalb auf low beim ersten Aufruf von SPI.transfer() schon auf low.
Habe die Routine jetzt so abgeändert:
pinMode(SPI_CS, OUTPUT);
pinMode(RF69_IRQ_PIN, INPUT); //wkl: Zeile eingefügt
unselect(); //wkl: Zeile eingefügt
SPI.setDataMode(SPI_MODE0);
SPI.setBitOrder(MSBFIRST);
SPI.setClockDivider(SPI_CLOCK_DIV64); //wkl: set to 64
SPI.begin();
Ob schon alles geht und ich auch Daten von der Wetterstation empfangen kann weiß ich noch nicht ganz genau, aber da mache ich morgen weiter. Sieht aber glaube ich gar nicht schlecht aus, siehe Screenshot.
Danke für die Unterstützung.
VG Wolfgang
so weit sieht es gut aus (Ausgabe FHEM).
bzgl. der Quellcode Änderung:
WriteReg ruft select auf und setzt damit CS auf LOW. Zwischen pinMode(SPI_CS, OUTPUT); und dem ersten WriteReg sind in beiden Sketches jeweils nur wenige Code-Zeilen. SPI schreibt lediglich einige Register in den Methoden vor begin.
ich habe v0.5 auf einem nano v3.3 (Atmel MEGA 328P) mit direkt angeschlossenen RFM69CW (ohne Widerstände) getestet.
das Problem ist, dass vor dem WriteReg kein SPI_CS high in irgend einer Form erzeugt wird. WriteReg verwendet zunächst select() damit wird aber SPI_CS auf low gesetzt, wo es ja eigentlich initial schon ist. Es fehlt das initiale, eindeutige setzen von SPI_CS high, bevor ein WriteReg() aufgerufen wird. Das kann man, wie in meinem Beitrag oben, durch den Aufruf von unselect() oder durch digitalWrite(SPI_CS, HIGH); erzeugen
pinMode(SPI_CS, OUTPUT);
pinMode(RF69_IRQ_PIN, INPUT); //wkl: Zeile eingefügt
digitalWrite(SPI_CS, HIGH); //wkl: Zeile eingefügt
SPI.setDataMode(SPI_MODE0);
SPI.setBitOrder(MSBFIRST);
SPI.setClockDivider(SPI_CLOCK_DIV64); //wkl: set to 64
SPI.begin();
Bei mir läuft es auf einem nano 3.0 aber mit Widerständen, wie im Schaltbild gezeigt, um die Signalpegel in der Spezifikation des RFM69CW zu halten (Richtung nano -> RFM69CW). Hier im Forum findet man zwar viele Hinweise, dass ohne Widerstände gearbeitet wird, ist aber eindeutig außerhalb der Spezifikation. Wenigstens ein Längswiderstand zur Eingansstrombegrenzung sollte verwendet werden. Ein zusätzlicher Unterschied zwischen ohne und mit Widerständen ist aber die max. SPI_CLK Frequenz. Durch die Widerstände und die Eingangskapazität des RFM69CW entsteht ein Tiefpass, der die CLK Signale so 'verschleift', dass die Logikpegel außerhalb der Schwellen liegen und deshalb die SPI Übertragung nicht funktioniert. Ich habe zwar die Widersände schon auf 470Ohm/1kOhm reduziert, aber trotzdem ist SPI_CLOCK_DIV2 zu optimistisch. Ich denke an der Stelle ist eine niedrigere CLK-Frequenz vom Gesamttiming auch unkritisch. Im Moment verwendet ich SPI_CLOCK_DIV64. Wenn Du ohne WIderstände arbeitest, wird es mit SPI_CLOCK_DIV2 auch gehen. Bei SPI_CLOCK_DIV64 dauert die Übertragung von 16bit ca. 63usec mit SPI_CLK ca 250kHz.
ergänzende UserReadings (http://forum.fhem.de/index.php/topic,44092.msg369267.html#msg369267) aktualisiert (5.7 Anpassungen)
Hallo,
ich würde den Sketch gerne für die Davis Wireless Leaf & Soil Moisture / Temperature Station erweitern. Bisher wird hier ja fest kodiert -1 weiter gegeben.
Die bisher fehlenden Details des Protokolls sind hier veröffentlich: https://github.com/cmatteri/CC1101-Weather-Receiver/wiki/Soil-Moisture-Station-Protocol
Allerdings sendet die Station nicht einfach nur einen Wert sondern beim Message Typ F gibt es weitere Unterwerte bzw. SubTypes (je bis zu 4 mal Soil Moisture, Temperature und Leaf Moisture).
Man bräuchte also passende Keys, die sich idealerweise ohne große Tabelle aus den im Protokoll gesendeten SubType und Port ergeben.
Wie wäre es mit 32 + 8*SubType+Port als Key?
Die gesendeten Werte sind auch nur roh gemessene Spannungen. Die Umrechnung in echte Temperatur / Feuchtigkeitswerte erfodert noch ein wenig Rechnen. Soll das in den Sketch oder eher in User-Readings?
Gruss
Stefan
Grundsätzlich habe ich kein Problem mit einer Erweiterung. Kannst du bitte die Rohdaten der betroffenen Daten posten, damit ich mir diese ansehen kann.
set jeelink raw 1p
Hallo,
anbei ein paar Rohdaten.
Ansatzweise habe ich mal folgendes in den Sketch eingefügt:
byte subType;
byte port;
...
case VP2P_SOIL_LEAF:
// https://github.com/cmatteri/CC1101-Weather-Receiver/wiki/Soil-Moisture-Station-Protocol
subType = packet[1] & 0x03;
port = (packet[1] >> 5) & 0x07;
if (subType == 1) {
val = (packet[2] << 2) + (packet[4] >> 6); // Soil Moisture
Serial.print((String)(32+port) + KEY_VALUE_DELIMITER + val + VALUE_DELIMITER);
val = (packet[3] << 2) + (packet[5] >> 6); // Soil Temp
Serial.print((String)(36+port) + KEY_VALUE_DELIMITER + val + VALUE_DELIMITER);
} else {
val = -1;
Serial.print((String)(40+port) + KEY_VALUE_DELIMITER + val + VALUE_DELIMITER);
}
break;
Da fehlt das Dictionary handling etc. und ob die Werte tatsächlich korrekt sind ist auch noch nicht klar.
Ich habe mal testweise versucht das Dictionary sinngemäß zu erweitern, allerdings gab es dann bei 12 weiteren Einträge seltsame Effekte: SendDictionary hat nur noch einen Teil der Einträge ausgegeben und ich befürchte dass das daran liegt dass der Variablenspeicher meines Jeelink übergelaufen ist. Ähnliche Probleme hatte ich mal bei der Entwicklung von ArduCounter.
Gruss
Stefan
ich habe mal KVPSensors.h aufgebohrt und neue Macros definiert.
getDictionary entsprechend ergänzen.
DictionaryValue(RSSI) +
DictionaryPortValue(SoilTemperature, 1) +
DictionaryPortValue(SoilMoisture, 1) +
DictionaryPortValue(SoilTemperature, 2) +
DictionaryPortValue(SoilMoisture, 2) +
DictionaryPortValue(SoilTemperature, 3) +
DictionaryPortValue(SoilMoisture, 3) +
DictionaryPortValue(SoilTemperature, 4) +
DictionaryPortValue(SoilMoisture, 4) +
DictionaryPortValue(LeafWetness, 1) +
DictionaryPortValue(LeafWetness, 2) +
DictionaryValue(PacketDump);
Ausgabe
port = ((packet[1] >> 5) & 0x07) + 1;
if (type == 1) {
val = (packet[2] << 2) + (packet[4] >> 6); // Soil Moisture
Serial.print(SensorDataPortValue(SoilMoisture, port, val));
val = (packet[3] << 2) + (packet[5] >> 6); // Soil Temp
Serial.print(SensorDataPortValue(SoilTemperature, port, val));
}
bei mir bleiben noch 683 Bytes für lokale Variablen übrig (vorher 839).
Daten sehe ich mir bei Gelegenheit an.
Vielen Dank schon mal.
Läuft es bei Dir denn auf einem Jeelink 3c mit den Änderungen?
Bei mir kommt im Terminal nur
[DAVIS.0.5 (RFM69 b:2)]
INIT DICTIONARY
Das Dictionary selbst fehlt ...
Gruss
Stefan[/code]
Einen Laufzeittest habe ich nur auf einem NodeMCU durchgeführt. Schreibe doch mal nur jeweils den ersten ins Dictionary.
Habe mir zwischenzeitlich überlegt, dass in SoilLeaf der Port übertragen werden kann und die im Packet vorkommenden Werte zusätzlich angehängt werden. Würde 7 defines sparen. Die neuen Makros würden auch entfallen.
Zitat von: StefanStrobel am 08 August 2016, 20:26:00
anbei ein paar Rohdaten.
2016-08-08_12:44:18 SMS PacketDump: f0-29-16-63-00-00-cf-71-ff-ff port 1, soil mois 88 (-9,9), soil temp 396 (12,27 °C)
2016-08-08_12:44:19 SMS PacketDump: f0-49-ff-ff-c0-c0-63-70-ff-ff port 2, kein Sensor
2016-08-08_12:44:29 SMS PacketDump: f0-09-28-5f-c0-80-7e-6e-ff-ff port 0, soil mois 163, soil temp 382
2016-08-08_12:44:32 SMS PacketDump: f0-29-16-63-00-00-cf-71-ff-ff port 1, soil mois 88, soil temp 396
2016-08-08_12:44:37 SMS PacketDump: f0-69-ff-ff-c0-c0-6b-c4-ff-ff port 3, kein Sensor
2016-08-08_12:44:40 SMS PacketDump: f0-0a-00-5f-40-80-39-a9-ff-ff port 0, leaf
2016-08-08_12:44:42 SMS PacketDump: f0-2a-00-63-40-00-10-51-ff-ff port 1, leaf
Entsprechen 12,27 °C der Erwartung? Für Moisture habe ich -9,9 errechnet.
v0.6 Anpassungen (SoilLeaf-Sensoren)
Der JeeLink mag den String nicht, der von getDictionary erzeugt wird.
Der Port wird jetzt in SoilLeaf gesendet. Zusätzlich werden die gefundenen Sensoren hinzugefügt.
Wie wird SoilMoisture ausgelesen. Habe nichts passendes gefunden.
Die Berechnungen sind recht tricky. Möchtest du das im Sketch versuchen?
Hallo,
wenn der Port in einem Reading steht und abhängig davon die Werte der SoilTemperature und SoilMoisture Readings zu interpretieren sind, wird das in Fhem für den Anwender recht unpraktisch. ohne zusätzliche User-Readings sind dann die Basiswerte nicht abrufbar bzw. wechseln ständig die Bedeutung.
Das Problem mit dem Dictionary-String auf einem Jeelink ist der Speicher. Durch die Verwendung der String-Klasse in den Makros wird hier zu viel belegt und fragmentiert.
Wenn man testweise z.B. die Wind-Readings auskommentiert, dann passen wieder ein paar Soil-Readings rein.
Ich würde vorschlagen, statt der komfortablen String-Klasse auf ein rudimentäreres Konstrukt zu wechseln. Auch wenn es momentan sehr elegant ist.
Zu den Umrechnungen mach ich mir mal Gedanken.
Gruss
Stefan
die zusätzlichen User-Readings sind der Preis für das KeyValueProtocol.
Über ein Notify lässt sich das bestimmt sehr einfach regeln.
Der Makro für SensorDataPortValue war zu optimistisch. Das ist ja Preprozessor-Kram. und der kann nichts mit dem sich dynamisch ändernden Port anfangen.
Der Port fällt als Wert auch an, wenn kein Sensor verbunden ist und ist somit der einzige Indikator, warum eine nachricht empfangen wurde.
Die Makros sind im Übrigen drin, damit zwischen Senden mit/ohne Dictionary hin und her geschaltet werden kann.
Hallo,
das Speicherproblem auf dem Jeelink scheint sich erledigt zu haben seit getDictionary weg ist und sendDictionary einzelne prints macht. Es spräche also nach meinem Verständnis nichts gravierendes mehr dagegen, für jeden Soil-Sensor auch ein eigenes Temperatur- und Feuchte-Reading anzubieten.
Die Keys könnte man aus der Portnummer ableiten - ähnlich wie ich es gepostet hatte.
Zwei weitere Dinge sind mir noch aufgefallen:
1) An meinem alten Pi klappt das Empfangen nach dem Einstecken eines Jeelinks erst nach einem jeelink reset.
Ein delay mit einer Sekunde vor der rfm Initialisierung behebt das Problem.
2) Die Umstellung de #include Anweisungen für die mitgebrachten .h files von "" auf <> erschwert das Kompilierne mit der Arduino IDE
Gruss
Stefan
Werden Daten sinnvoll empfangen (exkl. Berechnung)?
Welche Version der IDE benutzt du? Ich verwende 1.6.6.
Hallo,
der Empfang funktioniert prinzipiell und ich bin gerade an der Umrechnung der Werte.
Sobald es vernünftig aussieht, würde ich einen diff posten.
Zur Arduino IDE: ich verwende die 1.6.10. Entscheidend ist aber vermutlich dass ohne Anpassungen das aktuelle Verzeichnis des Sketches nicht im Standard-Include-Such-Pfad drin ist. Ein #include "vantage.h" funktioniert deshalb, ein #include <vantage.h> dagegen erst mit Anpassungen.
In den meisten Fällen hast Du ja auch die ""-Schreibweise für die eigenen Includes verwendet.
Gruss
Stefan
ich habe alle Dateien (exkl. ino) in einem Lib-Verzeichnis, da ich mehrere Sketches habe, die darauf zugreifen.
Hallo,
anbei mal ein Zwischenstand.
Wenn VERBOSE_SOIL definiert ist, gibt der Sketch nicht nur die Werte sondern auch die Zwischenwerte aus. Das macht das Testen einfacher.
Die Readings sehen dann bei mir so aus:
SoilMoisture1 -14.71 (127 Raw / 2.08 kOhm) (old 1.99 kOhm)
SoilMoisture2 -14.56 (128 Raw / 2.10 kOhm) (old 2.00 kOhm)
SoilTemperature1 20.45 (395 Raw / 12.27 kOhm) (old 12.27 kOhm)
SoilTemperature2 19.47 (406 Raw / 12.83 kOhm) (old 12.85 kOhm)
Die ausgegebenen Werte sind die Saugspannung des Bodens in kPa beziehungsweise cb. Wer hPa bevorzugt muss die Werte mit 10 multiplizieren. (siehe auch z.B. http://www.wetter-esslingen.info/bodenfeuchte.htm für die Interpretation)
Die unter https://github.com/cmatteri/CC1101-Weather-Receiver/wiki/Soil-Moisture-Station-Protocol veröffentlichten Formeln zur Berechnung der Widerstandswerte waren nicht optimal. Ich habe daher selbst nochmal eine Messreihe mit bekannten Widerständen gemacht. Die Davis Leaf and Soil Moisture/Temperature Station (LSMS) verwendet offensichtlich 3V als Ausgangsspannung für den Spannungsteiler. Bei den NTCs wird nach meinen Messungen ein 19,5 kOhm Widerstand für den Spannungsteiler verwendet, bei den WATERMARK 200SS Tensiometern ein 14,7kOhm Widerstand. Der Faktor, mit dem die gemessene Spannung multipliziert wird um den übertragenen Wert zu berechnen ist vermutlich 341. So kommt man auch bei 3V auf die maximal 10 Bit für die Werte.
Die neuen Formeln sind daher:
res = 19.5 / ((3 / (float)val * 341) -1); // temperature
res = 14.7 / ((3 / (float)val * 341) -1); // moisture
So passen die übertragenen Werte recht genau zu meinen Messungen. Besser als bei den bisher veröffentlichten Näherungsformeln.
Für die Umrechnung in die Temperaturen habe ich de Tabelle des Herstellers im Progmem abgelegt (http://www.davisnet.com/product_documents/weather/spec_sheets/6470_SS.pdf) und zwischen den Werten interpoliert. Für die Feuchtigkeitswerte habe ich die Formeln hier http://www.kimberly.uidaho.edu/water/swm/Calibration_Watermark2.htm verwendet.
Der Diff zum bisherigen Code ist angehängt.
Gruss
Stefan
Ich hatte übrigens immer noch das Problem dass ein Jeelink, wenn ich ihn aus und wieder eingesteckt habe, nichts empfangen hat. Jetzt habe ich die Ursache weiter eingrenzen können. Beim neu einstecken kommt im Jeelink-Modul bei Fhem nicht einfach nur [DAVIS.0.6d (RFM69 b:2)] an, sondern davor stehen im String viele Null-Bytes. Deshalb wird die Ausgabe nicht mit ^\[ gematcht und die Init-Befehle werden nicht gesendet.
Wo das herkommt ist mir noch nicht klar, aber als Workaround können wir den Sketch geringfügig ändern und vor der Begrüßung noch ein Newline senden. Dann scheint es zu klappen ...
Gruss
Stefan
Sketch v0.7 (Anpassungen von StefanStrobel bzgl. Berechnung SoilTemperature und SoilMoisture teilweise übernommen).
Hallo habeIchVergessen,
Bisher hast Du ja nur die Berechnung der Temperatur- und Saugspannungswerte aus den Roh-Werten übernommen,
aber beispielsweise nicht die Aufsplittung der Readings auf den jeweiligen Sensor bzw. Port.
Möchtest Du das noch tun?
Falls Nein, welchen Vorteil siehst Du darin dass sich die Werte von 4 Sensoren ein Reading teilen und so alle 3 Sekunden die Bedeutung wechseln?
Der Anwender kann das zwar weitgehend durch zusätzliche Programmierung in Ordnung bringen, aber mit ein paar Zeilen Code im Sketch hätte er für jeden Sensor ein eigenes Reading ...
Gruss
Stefan
1. aktuell kann per Define zwischen Senden mit/ohne Dictionary gewechselt werden (fehlte in deinem Code).
2. wenn ein Soil/Leaf-Packet empfangen wird und kein Sensor detektiert wurde, dann werden nur RSSI und Battery übertragen. Der eigentliche Grund (Art des Packets) verschwindet vollständig. Blacklisten würde ich auch nicht toll finden.
3. die Resourcen vom Arduino sind sehr limitiert und ich würde sie gern für das Wesentliche nutzen (Daten dekodieren und weiterreichen).
Wenn du Lust und Laune hast, dann versuch dich an o.g. und wir diskutieren weiter, wenn Aufwand (Resourcen) und Nutzen deutlich werden.
Für LeafWetness fehlt noch das korrekte Auslesen der Daten und die Berechnung. Gibt es diesbzgl. weitere Informationen?
Moisture wird aktuell nur ausgegeben, wenn die Temperatur mitgeliefert wird (bei der Berechnung notwendig). Eine Default-Temperatur von 24°C habe ich nicht eingebaut.
Sonstige Einwände bzgl. der leichten Abwandlungen?
Zitat
1. aktuell kann per Define zwischen Senden mit/ohne Dictionary gewechselt werden (fehlte in deinem Code).
2. wenn ein Soil/Leaf-Packet empfangen wird und kein Sensor detektiert wurde, dann werden nur RSSI und Battery übertragen. Der eigentliche Grund (Art des Packets) verschwindet vollständig. Blacklisten würde ich auch nicht toll finden.
baue ich gerne noch ein.
Zitat
3. die Resourcen vom Arduino sind sehr limitiert und ich würde sie gern für das Wesentliche nutzen (Daten dekodieren und weiterreichen).
Da bin ich prinzipiell Deiner Meinung. Dennoch wird es immer ein Kompromiss sein, bei dem auch Usability und sinnvolle Integration in FHEM eine Rolle spielen sollten.
Bei einer ganz konsequenten Linie um Ressourcen im Sketch zu sparen, müssten auch die Formeln zur Umrechnung in Userreadings ausgelagert werden. Ich halte das nicht für erstrebenswert, solange die Ressourcen es noch problemlos hergeben. Die reduzierte Verwendung von String-Objekten bzw. Nutzung von PROGMEM ist da ein offensichtlicherer Hebel.
Zitat
Wenn du Lust und Laune hast, dann versuch dich an o.g. und wir diskutieren weiter, wenn Aufwand (Resourcen) und Nutzen deutlich werden.
Zum Thema Nutzen:
Auch aus Sicht der FHEM-Integration würde ich von der bisherigen Variante abraten. Wenn ca. alle drei Sekunden ein Reading mit einem anderen Wert mit einer anderen Bedeutung in FHEM eingeliefert wird, gehen die üblichen Konstrukte wie event-on-change-reading .* ins Leere. Ohne aufwändigere Konfiguration wird jedes mal ein Event erzeugt.
Zitat
Für LeafWetness fehlt noch das korrekte Auslesen der Daten und die Berechnung. Gibt es diesbzgl. weitere Informationen?
Bisher habe ich nichts im Internet gefunden.
Es sollte aber nicht so schwer sein das noch zu reversen.
Ich habe gerade noch ein paar offene Baustellen bzw. Erweiterungswünsche bei meinen Fhem-Modulen, die ich implementieren möchte (insbes. Modbus und HTTPMODD), aber in den nächsten Wochen sollte das irgendwann noch reinpassen.
Zitat
Moisture wird aktuell nur ausgegeben, wenn die Temperatur mitgeliefert wird (bei der Berechnung notwendig). Eine Default-Temperatur von 24°C habe ich nicht eingebaut.
Ich denke ein Default-Wert von 24Grad sind nur sehr wenige zusätzliche Bytes im Code. Das sollte es wert sein.
Zitat
Sonstige Einwände bzgl. der leichten Abwandlungen?
Keine Einwände - nur Ergänzungsvorschläge :-)
Ein sleep 1000 zu Beginn hatte das Problem mit den Jeelinks doch noch nicht behoben. Nachdem ich mir das mit zusätzlichen Debug-Logs im Jeelink-Modul näher angesehen hatte, besteht die Lösung entweder in einem zusätzlichen Newline oder in einer kleinen Änderung der Regex im Jeelink-Modul, so dass die Null-Bytes weggeworfen werden (siehe mein vorletzter Post).
@Andre: falls Du mitliest, was meinst Du dazu?
Die eingefügten "const" im Code, die ich im Diff vorgeschlagen habe, entfernen einige Compiler-Warnings. Das ist nur kosmetischer Natur, sorgt aber bei unbedarfteren Anwendern für weniger Verwirrung und schadet sicher nichts.
Die <> Syntax, mit der Du die eigenen #include-Dateien des Sketches einbindest funktioniert nicht bei Anwendern, die einfach nur das Archiv extrahieren und das ganze in der neu installierten Arduino-IDE comilierten wollen. Du könntest entweder eine Anleitung dazu schreiben, wo man die jeweiligen Dateien hinkopieren soll oder aber für die hier veröffentlichte Version die Dateien mit "" includen.
Gruss
Stefan
Hallo habeIchVergessen,
ich habe inzwischen die Dekodierung der Leaf-Wetness-Meldungen (SubType 2) eingebaut. Interessanterweise wird zusammen mit Leaf-Wetness auch immer der Tempertaturwert mit der gleichen Portnummer mitgesendet. Die Kodierung der Temperatur ist dann identisch mit den Soil-Moisture- und Temperature-Meldungen bei SubType 1. Leaf-Wetness wird dabei in Byte 2 als 8-Bit Wert gesendet.
Daher habe ich die Reihenfolge im Programmcode so umgestellt, dass die Temperatur in beiden Fällen als erstes ausgewertet wird. Falls kein Temperatursensor vorhanden ist, gehe ich von den 24 Grad aus. Das könnte man natürlich noch wählbar machen.
Deine Variante der Interpolation für die Temperaturberechnung habe ich übernommen. Sie ist ohne Zweifel eleganter als mein erster Entwurf.
Zitat
3. die Resourcen vom Arduino sind sehr limitiert und ich würde sie gern für das Wesentliche nutzen (Daten dekodieren und weiterreichen).
Wenn du Lust und Laune hast, dann versuch dich an o.g. und wir diskutieren weiter, wenn Aufwand (Resourcen) und Nutzen deutlich werden.
Um das mit den Portnummern bei den Werten eleganter umsetzen zu können, war ich so frei Deine Präprozessor-Makros zur Ausgabe der Sensor-Werte durch Funktionsaufrufe zu ersetzen und die Tabelle der Namen explizit ins Progmem zu legen. Dadurch fällt einiges an Redundanz weg, die der Präprozessor sonst erzeugt hat und es wird deutlich einfacher Namen mit Suffixen (-1 bis -4) zu erzeugen. Damit die Tabelle einfacher indizierbar ist, habe ich die numerischen Keys auch ohne Lücken nummeriert. Ich hoffe das hat bei Dir keine negativen Seiteneffekte.
Das Senden mit / ohne Dictionary sollte ebenfalls funktionieren.
Für die Ressourcendiskussion ist damit auf jeden Fall trotz zusätzlicher Funktionen der verwendete Programmspeicher von 75% auf 70% und der verwendete Variablenspeicher von 57% auf 48% gesunken.
Um den Code auch in fremden Umgebungen ohne Verschieben der Includes zu erleichtern habe ich ein
#define LOCALINCLUDES 1
eingebaut. Vielleicht wäre das ja ein Kompromiss ...
Zitat
2. wenn ein Soil/Leaf-Packet empfangen wird und kein Sensor detektiert wurde, dann werden nur RSSI und Battery übertragen. Der eigentliche Grund (Art des Packets) verschwindet vollständig. Blacklisten würde ich auch nicht toll finden
Da sehe ich noch Diskussionsbedarf. Durch die neuen Funktionen zur Ausgabe der Sensorwerte könnte man jetzt auch die Ausgabe von Header, Channel, RSSI und Battery in eine Funktion auslagern und bei der ersten Ausgabe eines Sensorwertes aufrufen. Ob hier der Aufwand aber gerechtfertigt ist, würde ich anzweifeln. Id, Channel etc. müssten dann sinnvoll zwischengespeichert werden, es werden neue Flags nötig um den Header nur einmal auszugeben etc.
Mich stört es eigentlich nicht, wenn gelegentlich nur Battery und RSSI gemeldet werden.
Problematisch ist dabei auch dass auch die Debug-Ausgaben im Interrupt-Handler dazwischen funken können.
Anbei der Sketch mit meinen Änderungen / Erweiterungen
Gruss
Stefan
hab es schon mal kurz angeschaut. mir fehlt aktuell die Zeit zum Testen. Melde mich dann.
hat lange gedauert!
anbei ein Sketch, der sich für ein Arduino Uno/Nano und ESP8266 kompilieren lässt und die Änderungen zu Soil Temperature/Moisture und LeafWetness enthält. Bitte nur zu Testzwecken einsetzen und ggf. ein Feedback abgeben.
fhem-master.7z unter Windows in folgendes Verzeichnis entpacken (Arduino IDE neu starten)
%USERPROFILE%\Documents\Arduino\libraries
Hallo,
ich überlege mir gerade eine Wetterstation zu kaufen.
Die Vantage PRO 2 sagt mir schon ziemlich zu, jedoch wäre mir sehr wichtig das meine neue Wetterstation fast alles in FHEM überträgt.
Kann mir jemand sagen welche Daten nun tatsächlich in FHEM gelesen werden können?
LG Jens
grundsätzlich sollten die Readings für Wind (Richtung, Stärke, Böe), Temperatur, Luftfeuchtigkeit, Regen (Tip-Count, Sekunden), Batterie + RSSI geliefert werden. Bei den Ausführungen mit Solar eben auch die Spannung am Panel + Kapazität Kondensator. Letzere sind von der Vantage Vue. Ggf. muss hier die Software (Sketch) angepasst werden.
Ansonsten finden sich hier (http://forum.fhem.de/index.php/topic,44092.msg369267.html#msg369267) weiterführende Infos zu berechneten Werten, die auf den Readings basieren.
Hallo,
ich habe mir einen NanoJeeLink mit dem RFM69CW zusammen gebastelt und in fhem eingebunden.
model: [DAVIS.0.7e (RFM69 b:2)]
initCommands: 0,0s 1r
Leider erhalte ich als RAWMSG: OK VALUES DAVIS 0 17=2,19=73,18=ok,4=0.00,5=55,8=55 und nicht Battery, Temperature, Humidity....
Ich kann leider beim durchflöhen des Scetches und der beteiligten fhem Module nich heraus finden, was die Ursache ist, habt Ihr einen zweckdienlichen Hinweis für mich?
Wenn ich wüsste, für welchen Sensorwert die Zahlen stehen, könnte ich über UserReadings ja umschlüsseln.
Danke schon einmal
reisner
ich denke, es liegt an diesem auskommentierten define "// #define KVP_LONG_KEY_FORMAT 1"
reisner
nach dem Booten vom Nano sollte eine Zeile ausgegeben werden, die mit INIT beginnt.
In dieser steht das Mapping. Sollte von JeeLink entsprechend erkannt werden und von KeyValueProtocol-Device auch gelesen werden, sofern dass Attribute Mapping dort nicht existiert. Kannst du bitte mal ein list für die beiden Devices posten?
list JeeLink:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB2@57600
Davis_MSGCNT 19449
Davis_TIME 2017-09-07 10:21:38
DeviceName /dev/ttyUSB2@57600
FD 48
NAME Davis
NR 206
PARTIAL
RAWMSG OK VALUES DAVIS 0 17=1,19=70,18=ok,4=1.61,5=55,3=81,
STATE opened
TYPE JeeLink
initMessages
model [DAVIS.0.7e (RFM69 b:2)] config: 2b 0r
Matchlist:
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:KeyValueProtocol ^OK\sVALUES\s
Readings:
2017-09-07 10:28:11 state opened
Attributes:
event-min-interval 60
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 0,0s 1r
room Davis,System
list KeyValue Protocol:
Internals:
DEF DAVIS 0
Davis_MSGCNT 19449
Davis_RAWMSG OK VALUES DAVIS 0 17=1,19=70,18=ok,4=1.61,5=55,3=81,
Davis_TIME 2017-09-07 10:21:38
ID DAVIS_0
IODev Davis
LASTInputDev Davis
MSGCNT 19449
NAME KeyValueProtocol_DAVIS_0
NR 207
STATE Initialized
TYPE KeyValueProtocol
model DAVIS
Readings:
2017-09-07 10:21:30 1 14.72
2017-09-07 10:21:38 17 1
2017-09-07 10:21:38 18 ok
2017-09-07 10:21:38 19 70
2017-09-07 10:21:38 3 81
2017-09-07 10:21:38 4 1.61
2017-09-07 10:21:38 5 55
2017-09-07 10:21:28 6 9.65
2017-09-07 10:21:28 7 6
2017-09-07 10:21:33 8 90
2017-09-07 10:21:36 9 -1
2017-09-07 10:21:30 DewPoint 11.12
Attributes:
IODev Davis
event-min-interval *:60
room Davis,KeyValueProtocol
userReadings DewPoint:(1.*|3.*) { sprintf("%.2f", ReadingsVal("KeyValueProtocol_DAVIS_0", "1", 0) - (100 - ReadingsVal("KeyValueProtocol_DAVIS_0", "3", 99)) / 5.0);; }
bei meinem JeeLink-Device gibt es das Internal initMessages. dort steht die ersten Nachricht aus dem Sketch (wenn nicht KVP_LONG_KEY_FORMAT definiert ist). Diese wird vom KeyValueProtocol-Device gelesen und für das Mapping herangezogen.
Internals:
CFGFN fhem_davis.cfg
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 35
NAME davisJeeLink
NR 202
PARTIAL
RAWMSG OK VALUES DAVIS 0 20=1,22=-62,21=ok,4=0.00,5=255,8=24,
STATE initialized
TYPE JeeLink
davisJeeLink_MSGCNT 1218720
davisJeeLink_TIME 2017-09-07 19:40:37
initMessages INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSecs,10=Solar,11=VoltageSolar,12=VoltageCapacity,13=SoilLeaf,14=UV,20=Channel,21=Battery,22=RSSI,255=PacketDump,
model [DAVIS.0.6 (RFM69 b:2)]
Matchlist:
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:KeyValueProtocol ^OK\sVALUES\s
Readings:
2017-09-07 19:40:37 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 0,16s r
Davis-Device
Internals:
CFGFN fhem_davis.cfg
DEF DAVIS 0
ID DAVIS_0
IODev davisJeeLink
LASTInputDev davisJeeLink
MSGCNT 1218338
NAME VantageVue
NR 203
STATE Initialized
TYPE KeyValueProtocol
davisJeeLink_MSGCNT 1218872
davisJeeLink_RAWMSG OK VALUES DAVIS 0 20=3,22=-62,21=ok,4=0.00,5=257,8=24,
davisJeeLink_TIME 2017-09-07 19:48:50
model DAVIS
Helper:
Dblog:
Humidity:
Dbhistdatalog:
TIME 1504806178.95634
VALUE 76.00
Pressure:
Dbhistdatalog:
TIME 1504803616.43996
VALUE 1010
Rainamount:
Dbhistdatalog:
TIME 1504786500.67796
VALUE 0
Rainamounttotal:
Dbhistdatalog:
TIME 1504785599.45913
VALUE 1033.6
Rainsecs:
Dbhistdatalog:
TIME 1504786626.99847
VALUE -1
Raintipcount:
Dbhistdatalog:
TIME 1504785599.45913
VALUE 24
Temperature:
Dbhistdatalog:
TIME 1504806483.89835
VALUE 14.94
Winddirection:
Dbhistdatalog:
TIME 1504806504.39456
VALUE 257
Windspeed:
Dbhistdatalog:
TIME 1504806522.33656
VALUE 0.00
State:
Dbhistdatalog:
TIME 1500639252.37319
VALUE Pressure:
Readings:
2017-09-07 19:48:50 Battery ok
2017-09-07 19:48:50 Channel 3
2017-09-07 19:48:03 DewPoint 10.14
2017-09-07 19:48:06 Humidity 76.00
2017-09-07 19:48:50 Pressure 1010
2017-09-07 19:48:50 RSSI -62
2017-09-07 14:15:00 RainAmount 0
2017-09-07 13:59:59 RainAmountTotal 1033.6
2017-09-07 19:48:42 RainSecs -1
2017-09-07 19:48:50 RainTipCount 24
2017-09-07 19:48:44 Temperature 14.94
2017-09-07 19:48:16 VoltageCapacity 8.34
2017-09-07 19:48:26 VoltageSolar 444
2017-09-07 19:48:42 WindChill
2017-09-07 19:48:50 WindDirection 257
2017-09-07 19:48:42 WindForce 0
2017-09-07 19:48:50 WindSpeed 0.00
2017-09-07 19:48:50 _IsRaining 0
2017-09-07 14:15:00 _LastRainTipCount 24
2017-09-07 13:59:59 _LastRainTipCountTotal 24
Attributes:
IODev davisJeeLink
event-min-interval Pressure:3600, Humidity:3600
event-on-change-reading .*
event-on-update-reading _LastRainTipCount
userReadings _IsRaining { (ReadingsVal("HM_RegenSensor.Status", "state", "dry") eq "dry" ? 0 : 1) }, DewPoint:(Temperature.*|Humidity.*) { sprintf("%.2f", ReadingsVal("VantageVue", "Temperature", 0) - (100 - ReadingsVal("VantageVue", "Humidity", 99)) / 5.0); }, WindChill:(WindSpeed.*|Temperature.*) { my $wc; my $ws = (ReadingsVal("VantageVue", "WindSpeed", 0) ** 0.16); my $temp = ReadingsVal("VantageVue", "Temperature", 0); my $calc = 13.12 + 0.6215 * $temp - 11.37 * $ws + 0.3965 * $temp * $ws; $wc = sprintf("%.2f", $calc) if ($calc < $temp); }, WindForce:WindSpeed.* { my $wf; my $ws=ReadingsVal("VantageVue", "WindSpeed", 0.00); $ws=~s/(\d+)\.\d+/$1<1?0:($1<6?1:($1<12?2:($1<20?3:($1<29?4:($1<39?5:($1<50?6:($1<62?7:($1<75?8:($1<89?9:($1<103?10:($1<117?11:12)))))))))))/eg; $wf=sprintf("%d", $ws); }, Pressure { ReadingsVal("BMP180", "Pressure", "") }
was liefert folgendes Kommando?
fhem> version (36_JeeLink|36_KeyValueProtocol)
File Rev Last Change
36_JeeLink.pm 12695 2016-12-01 21:38:18Z justme1968
36_KeyValueProtocol.pm 12157 2016-09-13 11:23:02Z hcs-svn
Hi,
folgende Versionsinfo bekomme ich:
36_JeeLink.pm 12695 2016-12-01 21:38:18Z justme1968
36_KeyValueProtocol.pm 13429 2017-02-18 11:46:50Z HCS
Bei mir wird offensichtlich die initMessages nicht gefüllt, ich habe kurzerhand das attribut Mapping manuell gefüllt und somit läuft es nun auch wie gewünscht.
Ich danke Dir trotzdem schon mal für deinen Einsatz!
wünsche ein schönes WE.
reisner
Hallo allerseits,
ich mir einen fertig gebauten Jeelink mit dem richtigen Chip für eine Davis Vanatge Pro gekauft.
Leider bekomme ich den Empfänger nicht an eine Vantage Pro geflascht.
Auch an einem anderen Raspi habe ich das gleiche Problem..
Weiß jemand Rat?
Danke awa
beim Flash wurde der JeeLink nicht gefunden. Hat noch eine LaCross-Firmware.
Hallo habeIchVergessen,
das dachte ich mir auch. Was muss ich machen, damit er gefunden wird, bzw. geflasht wird?
Auch beim flash direkt auf der Konsole wird keine Vantage Software aufgespielt..
Besten Dank
awa
poste doch mal das flash-Command
avrdude ...
hallo,
hier der Auszug aus dem logFile
flashing JeeLink myJeeLink
detected Firmware: DavisVantage.hex
hex file: ./FHEM/firmware/JeeLink_DavisVantage.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -b 57600 -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_DavisVantage.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x00
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x00
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
Hier der attribut
flashCommand avrdude -p atmega328P -b 57600 -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] deleteattr
aus dem Fhem device
Besten Dank
awa
avrdude -p atmega328P -b 57600 -c arduino -P /dev/ttyUSB0 -v
lösche mal das Device in fhem und probiere verschiedene Baud-Raten in der Konsole.
bei einem orginal-JeeLink gibt es noch den Reset-Taster. Welche hardware benutzt du?
Hallo allerseits,
guten Abend,
Device gelöscht, Fhem neu gestartet, Device Jeelink mit 57600 Baud neu angelegt.
Hier der LogFile Auszug:
2018.04.03 22:52:17 3: Opening myJeeLink device /dev/ttyUSB0
2018.04.03 22:52:17 3: Setting myJeeLink serial parameters to 57600,8,N,1
2018.04.03 22:52:18 3: myJeeLink device opened
2018.04.03 22:56:23 3: Opening myJeeLink device /dev/ttyUSB0
2018.04.03 22:56:23 3: Setting myJeeLink serial parameters to 57600,8,N,1
2018.04.03 22:56:24 3: myJeeLink device opened
2018.04.03 22:56:25 5: JeeLink/RAW: /[DAVIS.0.2 (RFM69 b:2)]
2018.04.03 22:56:25 5: SW: 0,16s
2018.04.03 22:56:25 5: SW: r
2018.04.03 22:56:26 5: JeeLink/RAW: /INIT DICTIONARY 1=Temperature,2=
2018.04.03 22:56:26 5: JeeLink/RAW: INIT DICTIONARY 1=Temperature,2=/Pressure,3=Humidity,4=WindSpeed,
2018.04.03 22:56:26 5: JeeLink/RAW: INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,/5=WindDirection,6=WindGust,7=Win
2018.04.03 22:56:26 5: JeeLink/RAW: INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=Win/dGustRef,8=RainTipCount,9=RainSe
2018.04.03 22:56:26 5: JeeLink/RAW: INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSe/cs,10=Solar,11=VoltageSolar,12=V
2018.04.03 22:56:26 5: JeeLink/RAW: INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSecs,10=Solar,11=VoltageSolar,12=V/oltageCapacity,13=SoilLeaf,20=Ch
2018.04.03 22:56:26 5: JeeLink/RAW: INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSecs,10=Solar,11=VoltageSolar,12=VoltageCapacity,13=SoilLeaf,20=Ch/annel,21=Battery,22=RSSI,255=Pac
2018.04.03 22:56:26 5: JeeLink/RAW: INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSecs,10=Solar,11=VoltageSolar,12=VoltageCapacity,13=SoilLeaf,20=Channel,21=Battery,22=RSSI,255=Pac/ketDump,
Baudrate auf 28800 geändert:
Logfile:
2018.04.03 23:05:14 3: Opening myJeeLink device /dev/ttyUSB0 2018.04.03 23:05:14 3: Setting myJeeLink serial parameters to 28800,8,N,1 2018.04.03 23:05:15 3: myJeeLink device opened 2018.04.03 23:05:15 5: JeeLink/RAW: /ƅ� 2018.04.03 23:05:16 5: JeeLink/RAW: ƅ�/A{F �R �F + 2018.04.03 23:05:16 5: JeeLink/RAW: ƅ�A{F �R �F +/Z 2018.04.03 23:05:16 5: myJeeLink: dispatch \000ƅ�A{\022F\f�R�F\017\037+\032Z 2018.04.03 23:05:16 3: myJeeLink: Unknown code ƅ�A{F �R�F +Z, help me! 2018.04.03 23:05:16 5: JeeLink/RAW: /ᡣ V��p�4 �� 2018.04.03 23:05:39 3: CCURPC: CB2001 Received 500 events from CCU since last check avrdude: Version 6.3 Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ (http://www.bdmicro.com/) Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is "/etc/avrdude.conf" Using Port : /dev/ttyUSB0 Using Programmer : arduino Overriding Baud Rate : 28800 avrdude: serial_baud_lookup(): Using non-standard baud rate: 28800 AVR Part : ATmega328P Chip Erase delay : 9000 us PAGEL : PD7 BS2 : PC2 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 200 StabDelay : 100 CmdexeDelay : 25 SyncLoops : 32 ByteDelay : 0 PollIndex : 3 PollValue : 0x53 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00 calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 Programmer Type : Arduino Description : Arduino Hardware Version: 2 Firmware Version: 1.16 Vtarget : 0.0 V Varef : 0.0 V Oscillator : Off SCK period : 0.1 us avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e950f (probably m328p) avrdude done. Thank you. 2018.04.03 23:06:25 3: Opening myJeeLink device /dev/ttyUSB0 2018.04.03 23:06:25 3: Setting myJeeLink serial parameters to 28800,8,N,1 2018.04.03 23:06:26 3: myJeeLink device opened 2018.04.03 23:06:26 5: JeeLink/RAW: /���� 2018.04.03 23:06:27 5: JeeLink/RAW: ����/�[Bh 2018.04.03 23:06:27 5: JeeLink/RAW: �����[Bh/�]h O���U�BW�OBA��� 2018.04.03 23:07:04 3: Opening myJeeLink_2 device /dev/ttyUSB0 2018.04.03 23:07:04 3: Setting myJeeLink_2 serial parameters to 57600,8,N,1 2018.04.03 23:07:05 3: myJeeLink_2 device opened 2018.04.03 23:09:00 3: Opening myJeeLink device /dev/ttyUSB0 2018.04.03 23:09:00 3: Setting myJeeLink serial parameters to 28800,8,N,1 2018.04.03 23:09:01 3: myJeeLink device opened 2018.04.03 23:09:02 5: JeeLink/RAW: /�� 2018.04.03 23:09:02 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink_2) 2018.04.03 23:09:02 3: Setting myJeeLink_2 serial parameters to 57600,8,N,1 2018.04.03 23:09:04 1: /dev/ttyUSB0 reappeared (myJeeLink_2) 2018.04.03 23:09:40 3: Opening myJeeLink device /dev/ttyUSB0 2018.04.03 23:09:40 3: Setting myJeeLink serial parameters to 28800,8,N,1 2018.04.03 23:09:41 3: myJeeLink device opened 2018.04.03 23:20:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
... Leider kein Empfang von verwertbaren Daten
ich flash dann wieder auf 57600 Baud
Logfile:
flashing JeeLink myJeeLink (http://192.168.178.111:8085/fhem?detail=myJeeLink) detected Firmware: DavisVantage.hex hex file: ./FHEM/firmware/JeeLink_DavisVantage.hex port: /dev/ttyUSB0 log file: ./log/JeeLinkFlash.log myJeeLink (http://192.168.178.111:8085/fhem?detail=myJeeLink) closed command: avrdude -p atmega328P -b 57600 -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_DavisVantage.hex 2>./log/JeeLinkFlash.log --- AVRDUDE --------------------------------------------------------------------------------- avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s avrdude: Device signature = 0x1e950f (probably m328p) avrdude: reading input file "./FHEM/firmware/JeeLink_DavisVantage.hex" avrdude: input file ./FHEM/firmware/JeeLink_DavisVantage.hex auto detected as Intel Hex avrdude: writing flash (25542 bytes): Writing | ################################################## | 100% 7.81s avrdude: 25542 bytes of flash written avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_DavisVantage.hex: avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_DavisVantage.hex: avrdude: input file ./FHEM/firmware/JeeLink_DavisVantage.hex auto detected as Intel Hex avrdude: input file ./FHEM/firmware/JeeLink_DavisVantage.hex contains 25542 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 5.91s avrdude: verifying ... avrdude: 25542 bytes of flash verified avrdude done. Thank you. --- AVRDUDE --------------------------------------------------------------------------------- myJeeLink (http://192.168.178.111:8085/fhem?detail=myJeeLink) opened
.... und das Device...
| CFGFN | |
| Clients | :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol |
| | /dev/ttyUSB0@57600 |
| |
| DeviceName | /dev/ttyUSB0@57600 |
| FD | 12 |
| NAME | myJeeLink |
| NR | 26 |
| PARTIAL | |
| RAWMSG | ƅ�A{F �R�F +Z |
| STATE | opened |
| TYPE | JeeLink |
| initMessages | INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSecs,10=Solar,11=VoltageSolar,12=VoltageCapacity,13=SoilLeaf,20=Channel,21=Battery,22=RSSI,255=PacketDump |
| model | [DAVIS.0.2 (RFM69 b:2)] |
| myJeeLink_MSGCNT | 1 |
| myJeeLink_TIME | 2018-04-03 23:05:16 |
Readings | state | opened | 2018-04-03 23:42:01 |
Jemand eine Idee, VanatgePro Indoor Sattion steht 20 cm neben dem JeeLink
Besten Dank
awa
Zitat von: wagenkna am 03 April 2018, 23:48:41
2018.04.03 22:56:25 5: JeeLink/RAW: /[DAVIS.0.2 (RFM69 b:2)]
jetzt ist ein Davis-Sketch geflasht. am Anfang findet eine Synchronisierung statt. danach sollten OK VALUES Zeilen folgen.
0,16s ist eine Vantage Vue!
probier mal 0,0s
ansonsten kann mit raw ein Kommando direkt an den JeeLink gesendet werden. z.B. 3p schaltet die Ausgabe aller empfangener Daten frei (quasi debug).
das Testen der Baud-Rate gilt dem Boot-Loader vom atmega328p. avrdude führt ein Reset des USB-Sticks aus und versucht den Boot-Loader zu erkennen.
Hallo habichvergessen,
ich hab mal das v0.7 sketch aufgespielt...
model [DAVIS.0.7 (RFM69 b:2)]
hier der Auszug aus dem Logfile..
2018.04.04 12:09:05 5: JeeLink/RAW: /[DAVIS.0.7 (RFM69 b:2)]
INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSecs,10=Solar,11=VoltageSolar,12=VoltageCapacitor,13=SoilLeaf,14=UV,15=SoilTemperature,16=SoilMoisture,
2018.04.04 12:09:05 5: SW: 0,0s
2018.04.04 12:09:05 3: myJeeLink_2: Unknown code 17=LeafWetness,20=Channel,21=Battery,22=RSSI,255=PacketDump,, help me!
es werden aber weiterhin keine Daten empfangen... Die Readings bleiben bei 12:09 stehen...
sonst noch eine Idee??
Besten Dank
awa
"nur" die ,16 in ,0 ändern! das endende " r" muss bleiben!
im ersten Post steht hinter "0,16s r" ein Link, der Erklärungen für die Kommandos liefert.
Mit v0.7 sollte 1D ohne Frequenzhopping die Nachrichten auf Kanal 0 ca. 3x pro Minute ausgeben.
Hallo habeichVergessen,
auch das "r" brachte keinen Empfang von Daten...
Im Original Zustand wurde ein LaCrosse Thermometer gefunden...
Woran liegt es, dass keine Daten Empfangen werden?
Besten Dank
awa
set myJeeLink raw s
set myJeeLink raw v
führe bitte die Kommandos aus und poste die Ausgabe.
ggf. direkt über die serielle Konsole der Arduino IDE eingeben (nur die Buchataben).
Hallo,
set myJeeLink raw s:
2018.04.04 21:34:25 4: set myJeeLink raw s
2018.04.04 21:34:25 5: SW: s
2018.04.04 21:34:25 5: JeeLink/RAW: /[DAVIS.0.2 (RFM69 b:2)] stations: 1
#0: 0,0 a
2018.04.04 21:34:25 5: myJeeLink: dispatch #0: 0,0 a
2018.04.04 21:34:25 3: myJeeLink: Unknown code #0: 0,0 a, help me!
2018.04.04 21:34:25 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink_2)
2018.04.04 21:34:25 3: Setting myJeeLink_2 serial parameters to 57600,8,N,1
2018.04.04 21:34:26 1: /dev/ttyUSB0 reappeared (myJeeLink_2)
set myJeeLink raw v
2018.04.04 21:36:46 4: set myJeeLink raw v
2018.04.04 21:36:46 5: SW: v
2018.04.04 21:36:46 5: JeeLink/RAW: /[DAVIS.0.2 (RFM69 b:2)] config: 2b 0,0s
2018.04.04 21:36:46 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink_2)
2018.04.04 21:36:46 3: Setting myJeeLink_2 serial parameters to 57600,8,N,1
2018.04.04 21:36:47 1: /dev/ttyUSB0 reappeared (myJeeLink_2)
ich hoffe es hilft weiter, besten dank für deine Unterstützung
Grüße
awa
set myJeeLink raw 3p 1D
Hallo,
hier der Log
018.04.04 21:57:18 4: set myJeeLink raw 3p 1D
2018.04.04 21:57:18 5: SW: 3p 1D
Besten Dank
Nach etwas warten Nichts, das mit OK beginnt?
welchen Sensor hat LaCross empfangen?
nö, nix, hab extr 5 min gewartet...
Im Device hat sich die Zeile RAWMSG geändert
Auszug Device Jeelink:
Clients
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF
/dev/ttyUSB0@57600
DeviceName
/dev/ttyUSB0@57600
FD
11
NAME
myJeeLink
NR
22
PARTIAL
RAWMSG
#0: 0,0 a
STATE
initialized
TYPE
JeeLink
initMessages
model
[DAVIS.0.2 (RFM69 b:2)] config: 2b 0,0s
myJeeLink_MSGCNT
1
myJeeLink_TIME
2018-04-04 21:34:25
Readings
state
initialized
2018-04-04 21:34:25
Welchen Sensor empfangen wurde weiß ich nicht,
hab aber das Device noch nicht gelöscht...
DEF
08
IODev
myJeeLink
NAME
01thermo
NR
21
STATE
T: 11.9
TYPE
LaCrosse
addr
08
corr1
0
corr2
0
Readings
battery
ok
2018-04-02 23:36:53
state
T: 11.9
2018-04-02 23:35:53
temperature
11.9
2018-04-02 23:36:53
Merci vielmals
Axel
wir sollten ohne fhem testen.
kannst du die serielle Konsole der Arduino IDE starten?
unter Windows funktioniert putty ganz gut.
da dann das initCommand abschicken und die Ausgabe posten
wenn du mir schreibst, wie die Arduino IDE gestartet wird??
Putty läuft..
putty auf die serielle Schnittstelle mit den Einstellung aus fhem 57600,8,n,1 starten.
Ausgabe sollten mind. 2 Zeilen sein. dann das initCommand senden. zusätzlich kannst du noch "3p s v" eingeben.
sorry, wenn ich den set myJeeLink raw 3p 1D eingebe, kommt keine ausgabe...
kann ich direkt auf der Komandozeile arbeiten??
ja.
unter Windows putty oder Arduino IDE
unter Linux screen oder Arduino IDE
was hast du zur Verfügung?
putty unter window, spc, und Arduino IDE hab ich mittlerer weile auch installiert
Hallo zusammen,
ich habe einen JeeLink mit einem "aufgesattelten" BMP180 an einen Raspi angeschlossen, um damit die Werte einer Davis Vue empfangen zu können. Autocreate hat ein KeyValueProtocol_DAVIS_0 und ein KeyValueProtocol_BMP180_0 angelegt. Die Werte vom BMP180 (Luftdruck und Innen-Temp) werden sofort angezeigt. Die Werte von der Vue leider nur in großen Zeitabständen, z.B: 20:45 / 02:04 / 11:34. Kann es sein, dass sich die beiden Protokolle gegenseitig stören? Die angehängten Dateien zeigen die Readings von der Vue und die Internals des myJeeLink.
Wie bekomme ich stets aktuelle Werte von der Vue?
Gruß
Xanti19
bei mir werden in ca. 13s alle 5 Kanäle durchgespielt und auf 4/5 Nachrichten empfangen.
Hallo habeIchVergessen,
da scheint ja einiges bei den Internals des Davis-Protkolls zu fehlen :(
poste bitte mal ein list von jeelink
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 10
NAME myJeeLink
NR 21
PARTIAL
RAWMSG OK VALUES BMP180 0 1=31.50,2=993,
STATE initialized
TYPE JeeLink
initMessages INIT DICTIONARY 1=Temperature,2=Pressure,3=Humidity,4=WindSpeed,5=WindDirection,6=WindGust,7=WindGustRef,8=RainTipCount,9=RainSecs,10=Solar,11=VoltageSolar,12=VoltageCapacitor,13=SoilLeaf,14=UV,15=SoilTemperature,16=SoilMoisture,17=LeafWetness,20=Channel,21=Battery,22=RSSI,255=PacketDump,
model [DAVIS.0.7 (RFM69 b:2) + BMP180]
myJeeLink_MSGCNT 90
myJeeLink_TIME 2018-04-12 21:01:38
MatchList:
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:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2018-04-12 21:01:38 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 0,16s r
führe mal bitte die Kommandos in FHEM aus und poste die Ausgaben aus der Log-Datei (ca. 60s sollten reichen).
attr myJeeLink verbose 4
set myJeeLink raw 0r 1D
Die Logdatei gibt nur eine Zeile aus:
2018.04.12 21:26:12 4: set myJeeLink raw 0r 1D
Wenn ich es richtig gemacht habe. :-\
probier mal
set myJeeLink raw s
kannst du auch ein Schaltbild vom JeeLink posten? ggf. fehlt die Interrupt-Leitung D2 (atmega328) zu DIO0 (RFM69).
2018.04.12 21:57:11 4: set myJeeLink raw s
2018.04.12 21:57:11 3: myJeeLink: Unknown code #0: 254,16 a, help me!
254,16 sollte da nicht stehen.
kannst du den JeeLink von Strom trennen und nach ca. 10s wieder anschließen? raw s dann bitte wiederholen.
wenn da 0,16 steht, dann raw 0r 1D probieren.
ist der JeeLink ein clone oder orginal? wenn kein orginal, dann bitte ein Schaltbild posten.
2018.04.12 22:23:11 4: set myJeeLink raw s
2018.04.12 22:23:11 3: myJeeLink: Unknown code #0: 0,16 a, help me!
2018.04.12 22:23:47 4: set myJeeLink raw 0r 1D
Der JeeLink ist ein Clone, Schaltplan müsste ich beim Erbauer anfragen...
Hallo habeIchVergessen,
hier kommen die Bilder vom JeeLink und BMP180 inkl. Schaltbild.
eigentlich ok! ist der Funkchip ein RFM69CW?
probier bitte folgendes (verbose 4 und ins Log schauen)
set myJeeLink raw 0r 3p 1D
Ja, ist ein RFM69CW.
raw 0r 3p 1D hat nichts bewirkt.
habe keine Idee, was nicht passt.
hast du ein Oszi? / Würdest du zu Testzwecken deine Hardware zur Verfügung stellen?
Ich habe kein Oszi.
Heute morgen habe ich einen anderen JeeLink-Clone ohne BMP180 ausprobiert. Auch hier werden keine Werte geholt. Bei Internals steht unter PARTIAL:
�� ��s����LJ$�� �$����$� ������� �
Mache ich vielleicht beim Flashen etwas falsch. Die hex-Datei steht ja im Ordner firmware. Wofür sind die anderern Dateien .h und .cpp? Müssen die auch irgendwo hinkopiert werden?
.h und .cpp sind die Sourcen. Werden zum Flashen nicht benötigt.
was steht im Internal model am JeeLink-Device?
Partial sieht nach fehlerhafter Baud aus.
Ja stimmt, da an diesem Raspi noch ein NanoCul hängt, musste ich den neu geflashten JeeLink entsprechend einstellen: /dev/serial/by-path/....
Danach hat autocreate sofort das KeyValueProtocol_DAVIS_0 angelegt. Kurz danach wurden dann auch Werte angezeigt. Aber nur einmal, es folgen keine aktualisierten Werte.
raw 0r 1D gibt dies aus:
2018.04.14 16:03:42 4: set myJeeLink2 raw 0r 1D
2018.04.14 16:03:47 3: myJeeLink2: Unknown code OK DISCOVERY DAVIS 0 22=-81,, help me!
2018.04.14 16:03:55 3: myJeeLink2: Unknown code OK DISCOVERY DAVIS 0 22=-81,, help me!
>>.h und .cpp sind die Sourcen. Werden zum Flashen nicht benötigt.
Wann und wo werden sie denn benötigt?
nach dem zweiten Eintrag 2018.04.14 16:03:55 3: myJeeLink2: Unknown code OK DISCOVERY DAVIS 0 22=-81,, help me!
wurden einige Werte aktualisiert
Davis sendet auf 5 verschiedenen Frequenzen (Channel 0-4). Diese werden ca. alle 13s wiederholt abgefragt.
wenn Nachrichten empfangen werden, dann sollte sich mind. Channel ändern. Battery und Wind sind auch in jeder Nachricht enthalten.
Im Discovery-Mode (1D) wird "nur" auf Channel 0 empfangen. Ein ähnlicher Modus wird auch zu Beginn benutzt, um alle konfigurierten Stationen mindestens 1x auf Channel 0 zu sehen. Erst danach startet der eigentliche Empfang.
also JeeLink trennen und neu verbinden.
setze verbose 4 auf den JeeLink und beobachte die Nachrichten OK VALUES DAVIS 0 20=[Channel], ...
Alle 60s sollte OK VALUES BMP 0 empfangen werden (wenn BMP180 vorhanden).
RSSI -81 ist am unteren Ende der Empfangsempfindlichkeit.
Also:
JeeLink ohne BMP180: Nach dem Einrichten werden Werte übernommen, danach kann ich zwei drei Kanalwechsel erkennen, dann bleibt der JeeLink jedoch stehen, auch an der myJeeLink_TIME zu erkennen. Nach einem Reset des JeeLink werden sofort wieder aktuelle Werte geholt. Ich habe heute Morgen Raspi und JeeLink ca. 4 Meter von der Vue entfernt positioniert, der RSSI-Wert steht nun auf -62.
JeeLink mit BMP180: Es wird per autocreate nur ein KeyValueProtocol_BMP180_0 angelegt. Luftdruck und InnenTemp-werte werden alle 60s aktualisiert. KeyValueProtocol_DAVIS_0 fehlt... Update: Fast 4 Stunden später wurde nun auch das KeyValueProtocol_DAVIS_0 angelegt; Readings zeigt 6 Werte von 13:55 Uhr an, bis jetzt wieder Sendepause, Raspi steht etwas weiter weg, daher RSSI -76:
Battery ok 2018-04-15 13:55:07
Channel 4 2018-04-15 13:55:07
RSSI -76 2018-04-15 13:55:07
RainTipCount 91 2018-04-15 13:55:07
WindDirection 259 2018-04-15 13:55:07
WindSpeed 1.61 2018-04-15 13:55:07
um den Raspi als Ursache ausschließen zu können, mal bitte an einem PC probieren. einfach Putty auf der seriellen Schnittstelle mitlesen lassen. initCommands senden und warten.
Bis zur Anzeige im Terminalfenster habe ich es schon geschafft, kann aber keine Befehle eingeben... :-[
öffne ein Editor und schreibe dort die Kommandos
dann per cut & paste nach putty. wir Menschen sind zu langsam für den Automaten!
Ich fange dann mit initCommands 0,16s r an?
Sorry, wenn ich nachfragen muss, aber hier fehlt mir einfach das Hintergrundwissen... :(
ja
Anzeige nach initCommands 0,16s r:
#0: 0,16 a
OK VALUES BMP180 0 1=31.30,2=1003,
OK VALUES BMP180 0 1=31.50,2=1003,
zwischenzeitlich kannst du mit s den Status zu den Stationen abfragen.
list s:
[DAVIS.0.7 (RFM69 b:2) + BMP180] stations: 1
#0: 0,16 a
OK VALUES BMP180 0 1=29.30,2=1003,
OK VALUES BMP180 0 1=29.30,2=1003,
s alleine gibt nichts aus.
scheinbar wird die Vue nicht auf Channel 0 empfangen. damit startet dann auch nicht der reguläre Empfang.
So, die JeeLink-Variante ohne BMP180 hat sich nach gut drei Tagen eingependelt, sprich Wetterdaten werden ständig aktualisiert. Jetzt würde ich gerne das Speichern der Daten ausprobieren. Wie gehe ich da am besten vor? MySQL-DB? Werden dann alle aktualisierten Daten in die DB geschrieben, auch wenn sich vielleicht nur drei geändert haben?
Anders sieht es bei der Kombi mit BMP180 aus. Hier sind die Readings auf den Stand vom 15.04. stehen geblieben. BMP180-Werte werden alle 60s aktualisiert.
Hat denn eigentlich jemand so eine Kombi erfolgreich in Fhem eingebunden?
ich benutze sqlite als DB.
die nötigen Einstellung zu DbLog (Exclude..) und event-on-update/change-reading muss du ausprobieren. im 1. Post sind auch einige Verweise verlinkt.
BMP180 (I2C) und RFM69CW (SPI) sollten sich nicht gegenseitig stören. Lediglich der Stromverbrauch sollte sich ändern. Ggf. liegt hier das Problem.
Grundsätzlich hatte ich die Kombination mit Nano am laufen. Aktuell habe ich allerdings auf ein ESP8266 umgebaut.
Hallo,
ueberlege mir gerade eine vantage vue zu kaufen. Wieso wird hier der luftdruck nicht direkt von der vue geliefert?
mfg
wird von der Inneneinheit gemessen.
Zitat von: habeIchVergessen am 17 Juni 2018, 21:59:07
wird von der Inneneinheit gemessen.
Danke!
Hab nun die davis vue bestellt. Läuft das ganze stabil mit dem Jeelink?
ich habe ein orginal JeeLink im Einsatz. Er läuft seit Jahren stabil.
in früheren Post ging mind. 1x um einen Clone mit BMP180.
aktuell teste ich noch den Sketch mit einem ESP8266.
Zitat von: habeIchVergessen am 18 Juni 2018, 22:28:11
ich habe ein orginal JeeLink im Einsatz. Er läuft seit Jahren stabil.
in früheren Post ging mind. 1x um einen Clone mit BMP180.
aktuell teste ich noch den Sketch mit einem ESP8266.
Danke, läuft auch bei mir super!
Was bedeutet der Wert WindGustRef?
den gibt es nur, wenn Böen (WindGust) gemeldet werden. ist wohl eine Art Mittelwert der Windgeschwindigkeit, die der Ermittelung der Böe zugrunde lag.
Hallo,
ich habe eine Davis VP2 mit eurer Hilfe erfolgreich in eine Fhem-Instanz eingebunden. Die Readings werden auch mit dem Namen angezeigt.
Nun möchte ich dieses Device von meinen Haupt-Fhem mittels F2F abholen, was auch funktioniert. Die Kopplung funktioniert prima, aber die Readings kommen nur im Code 1=xx, 2=xx usw. rüber. Hat jemand einen Tipp. Auf einer anderen Fhem-Instanz mache ich das mit Lacrosse Temp.Sensoren, da klappt es mit den Namen des Readings.
Vielen Dank!!
Schau dir das Internal <Name I/O-Device>_Mapping an.
da steht 1=XYZ,2=
kopiere den Inhalt in ein Attribut Mapping in die 2. fhem-Instanz.
ggf. gibt es auch die Möglichkeit bei f2f. ich benutze die Funktionalität nicht und kann deshalb nur spekulieren.
Hallo!
@habeIchVergessen
Vielen Dank, das hat gefunzt. Ich lade meine Wetterdaten auf WU hoch. Nun habe ich noch das Problem mit dem Luftdruck und dem DewPoint.
Für den Luftdruck werde ich mir einen BMP180 zulegen. DewPoint,,,keine Ahnung.
Zitat von: t.moori am 13 August 2018, 19:29:31
DewPoint
s. ersten Post
Zitat von: habeIchVergessen am 15 November 2015, 12:13:53
ergänzende UserReadings (29.06.2016) (http://forum.fhem.de/index.php/topic,44092.msg369267.html#msg369267)
ansonsten gibt es in FHEM Module, die das automatisch berechnen.
@habeIchVergessen
Danke, da werde ich mich mal durchboxen!!
Viele Grüße
Vielen Dank habeIchVergessen!!
Funktioniert super. Wie Du schon mitbekommen hast bin ich kein Programmierer aber mir macht die Arbeit mit FHEM viel Spaß.
Vielleicht kannst Du mir auch sagen wie ich die alten Readings los werde? 1, 2, 20, 3, 12, usw., die werden auch nicht mehr aktualisiert.
Zitat von: t.moori am 14 August 2018, 18:23:11
Vielleicht kannst Du mir auch sagen wie ich die alten Readings los werde? 1, 2, 20, 3, 12, usw., die werden auch nicht mehr aktualisiert.
Mit deletereading. Schau mal in der Commandref
Billy
Vielen Dank Billy!!
@habeIchVergessen
was bedeuten interne Readings?
Zitat_IsRaining { (ReadingsVal("VantageVue", "RainAmount", 0) > 0.0 ? 1 : 0) }
Kann ich die Readings:
Reading für RainAmount, Reading für RainAmount (inkl. alte Werte aus DbLog lesen), und Reading nach 15 min. _LastRainTipCount mit RainTipCount synchronisieren nutzen, wenn ich den Devicename und den Datenbanknamen anpasse???
Besten Dank!!
ja. Die Anpassung der Namen ist notwendig.
Hallo
Zitat....$db="dbHistDataLog";
==> ist das der Datenbankname oder das LogDevice
und gehe ich richtig in der Annahme das _IsRaining ein UserReading ist??
Danke!
2x ja
Danke!
Kannst Du mir kurz die Fkt. der notify erklären??
grob: in den () hinter NOTIFY steht die Bedingung, wann der Perl-Code in den folgenden {} ausgeführt wird.
Guten Morgen habeIchVergessen,
ich habe folgende Fragen:
- Für die zwei NOTIFY
Zitat...VantageVue_RainAmount....
gilt entweder/oder(umbenennen)?
-
Zitatdefine myDavis6162_Wind SVG myDbLog:davis_wind:HISTORY
,
ist "davis_wind" ein Datensatz, bei mir müsste er aus 2Teilen bestehen: Device+Reading==> ich habs, wird im gplot-file aufgelöst
Danke und schönes WE!
Seit einem Jahr funktioniert die Einbindung in Fhem mit dem Clone sehr gut.
Für die Tablet-UI finde ich allerdings keinen Wert, der die Regenmenge vom aktuellen Tag anzeigt. Mit den ergänzenden UserReadings habe ich dies auch nicht realisieren können. Hier werden zwar in Fhem die Readings RainAmount, RainAmountTotal, RainSecs, RainTipCount, _LastRainTipCount und _LastRainTipCountTotal angezeigt, aber nicht die richtige Regenmenge von heute: 0.0.
Hat jemand eine Idee?
ein monotonic userReading liefert Tages-, Monats- und Jahreszahlen.
Sorry, aber die vorgeschlagene Umsetzung mit monotonic bekomme ich nicht hin. Es scheitert bei mir schon daran, welches Reading ich hierfür nehmen muss. :-[
Da ich die Anzeige des Tageswertes eigentlich nur für meine Tablet-UI brauche, habe ich RainTipCount mal testweise auf 0 gesetzt. Der Wert wird dann jedoch mit der nächsten Aktualisierung wieder auf den ursprünglichen Wert zurückgesetzt...
So, nach weiteren Versuchen (halber Sonntag) habe ich die folgenden UserReadings angelegt:
RegenmengeTagCount monotonic { ReadingsVal("VantageVue","RainTipCount",0);;},
RegenmengeTag none { ReadingsVal("VantageVue","RegenmengeTagCount",0)*0.2;;}
RegenmengeTagCount wird um 00:01 auf 0 gesetzt. Jetzt muss ich den nächsten Regen abwarten, um zu sehen, ob ich auf dem richtigen Weg bin... ;)
Hatte es vorher mit den Readings aus Antwort #101 versucht.
Es hat eben geregnet und sechs Wippenschläge wurden in RegenmengeTagCount korrekt eingetragen. Auch die RegenmengeTag stimmt. :)
Wie verhält sich eigentlich das Reading RainTipCount? Wird dieser Wert zu einem bestimmten Zeitpunkt oder Erreichen eines bestimmten Wertes auf 0 gesetzt?
RainTipCount geht von 0 bis 127.
zu dem monotonic userReading gehört dann noch ein statistics. Dieses berechnet dann basierend auf dem monotonic-Wert Tages-, Monats- und Jahres-Zähler.
Vielen Dank für die Info. Aktuell steht das Reading bei 112. Der Tageswert würde dann also bei mir nach dem Sprung von 127 auf 0 bei dem bis dahin berechneten Wert (RegenmengeTag) stehen bleiben. Kann man dies irgendwie abfangen? Ist allerdings für mich auch nicht so dramatisch.
Zitatzu dem monotonic userReading gehört dann noch ein statistics. Dieses berechnet dann basierend auf dem monotonic-Wert Tages-, Monats- und Jahres-Zähler.
Wäre schön, wenn Du hierfür ein Beispiel einstellen könntest.
monotonic
define KeyValueProtocol_Esp1wire_1d.a20000000101.6b KeyValueProtocol Esp1wire 1d.a20000000101.6b
attr KeyValueProtocol_Esp1wire_1d.a20000000101.6b alias Zaehler
attr KeyValueProtocol_Esp1wire_1d.a20000000101.6b IODev myKVPUDP
attr KeyValueProtocol_Esp1wire_1d.a20000000101.6b event-on-change-reading .*
attr KeyValueProtocol_Esp1wire_1d.a20000000101.6b userReadings Gas:(Counter.1.*) monotonic { ReadingsVal("KeyValueProtocol_Esp1wire_1d.a20000000101.6b", "Counter.1", 0)/100.0 }
statistics (abschließende "." sorgt für versteckte Readings .Gas)
define counterStats statistics KeyValueProtocol_Esp1wire_1d.a20000000101.6b .
attr counterStats ignoreDefaultAssignments 1
attr counterStats deltaReadings Gas
attr counterStats singularReadings KeyValueProtocol_Esp1wire_1d\.a20000000101\.6b:Gas:Delta:(Day|Month|Year)
verstecke Readings
list -r KeyValueProtocol_Esp1wire_1d.a20000000101.6b
Zitat von: habeIchVergessen am 06 Mai 2017, 00:32:17
hat lange gedauert!
anbei ein Sketch, der sich für ein Arduino Uno/Nano und ESP8266 kompilieren lässt und die Änderungen zu Soil Temperature/Moisture und LeafWetness enthält. Bitte nur zu Testzwecken einsetzen und ggf. ein Feedback abgeben.
fhem-master.7z unter Windows in folgendes Verzeichnis entpacken (Arduino IDE neu starten)
%USERPROFILE%\Documents\Arduino\libraries
Password für NodeMCU v0.7 (ESP8266)
Es wird danach gefragt...bei der WIFI Abfrage...
Falls es die Chip ID sein sollte, dann geht es nach der Eingabe nicht weiter.
Kein Konfigurationsfenster.
D.h. ich kann keine Ssid bzw. Schlüssel eingeben.
Auch lässt sich sich nicht die IP über den Browser öffnen. (Safari)
ERLEDIGT
Tablet und anderer Browser war die Lösung
NodeMCU v0.8b
unter Windows: die beiden anderen 7z-Dateien nach %USERPROFILE%\Documents\Arduino\libraries entpacken
unter Linux: entsprechenden symbolischen Link anlegen
Arduino IDE 1.8.9 oder besser 1.6.13
in Zeile 196 (NodeMCU.ino) steht noch das init-Command (GUI fehlt noch)
195 // register station, enable receive
196 handleInput('s', true, 0, true, 16);
Zeile 196 kopierst du und änderst dann die Werte. In meinem Beispiel ist es ID 0 (3. Parameter) als Vantage Vue (5. Parameter = 16). Die richtigen Werte findest du in Vantage.h (fhem-master library) Zeile 192 (// Davis VP2 standalone station types) und folgende. Meine 16 (0x10) ist STYPE_VUE.
NodeMCU v0.8c kompilierbar für Arduino Uno, Nano (kein Laufzeittest) und ESP8266, ESP32
neu: GUI für Stations-Setup
Binaries für Nano und Wemos D1 mini enthalten.
Jetzt compilliert es durch.....super ;)
Hallo,
wie komme ich in die GUI....nach der Eingabe über die Weboberfläche OK via Wemos Mini.
Leider kann ich erst mit dem Wemos weitermachen, wenn die neuen eingetroffen sind.....mein GPIO 15 ist defekt.
Aber wie komme ich auf den Nano der über USB steckt, dorthin?
Kann ja nur über Fhem sein...
Zudem habe ich beim Nano festgestellt, das kein BMP180 und kein BMP280 erkannt werden.
Grüße Dirk
du kannst mit
set JeeLink raw
Kommandos an einen Nano schicken. ggf. erscheint der Output dann im FHEM-log (habe ich lange nicht mehr benutzt)
den BMP180 hatte ich erst einmal ausgebaut, da ich seit dem letzten Arduino UNO/Nano-Build (v0.7) noch Unterstützung für einen BME680 in die library eingebaut habe. Da waren dann "nur" noch 250 Bytes freier Speicher übrig.
Wenn ich es schaffe, dann poste ich heute noch Sourcen, die den BMP180 wieder unterstützen.
wäre toll wenn der BMP280 unterstützt wird.
Danke
v0.8d - Codebase für Arduino Nano/Uno + ESP8266/32 (NodeMCU gibt es ab jetzt nicht mehr)
Firmware für Arduino mit Unterstützung für BMP180 und Wemos D1 mini BME680, BME280 und BMP180 (werden in der Reihenfolge gesucht und nur 1 unterstützt)
BMP280 ist "nur" ein Luftdrucksensor. Meinst du eventuell einen BME280?
Erst einmal Danke, für deine Mühe.
Ja, ich meine den BMP280.
Dürfte aber der selbe sein wie der BME.
Er kann Hygro, Baro und Temp
Siehe Anhang
Gruß Dirk
Leider kommt nach dem flashen deiner DAVIS v0.8d (Wemos D1 mini).bin
beim hinzufügen einer Station....
Kommt auch auf der Startseite, wenn ich den Schlüssel oder ssid abfragen will.
siehe Anhang
PS: Da mein Wemos heute gekommen ist, habe ich den Code NodeMCU v0.8c probiert. Da wird der RFM69 nicht erkannt...
Habe den fhem-master schon getauscht. Der BMP280 wird schön erkannt
I
per Java-Skript wird html-Injection benutzt, um den Inhalt dynamisch zu laden.
Bei mir funktioniert das in Firefox < 80 und den IE.
mit Firefox 80, chrome 85.0.4183.83, IE und Edge und Windows 10 getestet.
Gut,
mit dem Tablet und Firefox ging es dann.
Es wird bei mir kein RFM96 erkannt.
Es ist der gleiche wie mit dem Nano verbaut und auf Funktion überprüft.
Siehe Anhang.
Orginal Wemos Flash von dir.
Ich habe schon in der alten 07er festgestellt, das der RFM69 nicht erkannt wurde. Nach austausch der RFMxx.cpp und RFMxx.h
gegen ältere...ging es dann.
Gruß
Dirk
hast du noch eine Idee, aus welcher Version du die RFMxx-Dateien genommen hattest?
nach dem Flashen den Wemos mal stromlos gemacht?
Den Wemos mach ich nach dem flashen immer Stromlos...
Anbei das RFMxxx Pack das bei mir läuft.
hab irgendwann eingebaut, dass gpio2 zu verwenden ist, weil ich mir ein Wemos Shield gebastelt habe (s. Anhang).
Hatte wohl nicht so recht mit OTA funktioniert. Daher auf gpio 2 gewechselt und per Transistor die Flanke umgekehrt.
hab in Vantage.h das define _WEMOS_DAVIS_SHIELD eingebaut, um das Verhalten steuern zu können. Vorher wurde es stumpf über ESP8266 abgefragt.
neue Binaries und libraries im Anhang.
Supi,
teste ich morgen.
;)
Gruß
Dirk
Hallo,
wird leider immer noch nicht erkannt.
Du schreibst was von gpio0 und gpio2....sind beide offen bei mir.
Sollte der NSS statt an den gpio15 an den gpio0 ?
Ich habe nach folgenden Schaltplan gebaut.
Selbstverständlich sind die Pinouts an den Wemos angepasst.
Was anderes habe ich nicht.
Wie ich das auf deinem Layout erkennen kann, ist auch DI00 bei dir verschaltet.
Hängt hier in der Luft.
mein Schaltplan schaut so aus
gpio0/2 hängen am DIO0 vom RFM69
Ok,
ich hole noch einen Transistor und 2 Widerstände aus dem Keller.
Ein normaler NPN BC238C oder ähnl. sollte reichen, oder.
Ich weiß aber nicht, ob der Code wieder geändert werden muss...
Lässt du die 3,3V komplett über den Wemos laufen?.....der Spannungsregler kann doch nur 50mA
Habe von gestern den Code geflasht ohne deine Änderung, aber mit neuer Verschaltung.
Ist Wifi disconnect
Öffne ich DI00 und gpio2 wieder bleibt der ESP am Start.
Seriell ist er da....
Nochmal geflasht...während der Schlüsseleingabe ist der ESP wieder weg.
Nur noch zur Info:
Die Schaltung entspricht jetzt deiner, nur mit einen normalen NPN Transistor....habe kein SMD zur Hand.
...mit BMP280 und zusätzlicher Stromversorgung.
3V3 über Wemos: ja, nur die 5V Input vom USB (RFM69+BME280)
im seriellen Output steht, dass er den SoftAP gestartet hat. Meint dass keine WiFi-Connect mit den gespeicherten Werten möglich ist. Kannst du dich dann am neuen AP anmeden?
Was ist mit dem PullUp an gpio15 (CS)? den habe ich nicht drin.
Keine PullUp`s mehr drin......genauso wie bei dir
Ich habe alle nochmals Wiederholt.
ssid und Schlüssel Eingabe war jetzt OK, Fritzbox geöffnet Link angeklickt geht nicht auf.
ESP-577B18 steht drin....
Beim Tablet, Laptop, PC und Handy nicht.
Mir raucht der Kopf langsam. ;)
esp_577B18 ist der default-hostname
Das ist mir schon klar, nur lässt sich nichts öffnen. Wie ich schon schrieb.
In eine leere Seite kann ich keine Station eingeben.
Ich werde nochmal selbst compillieren.
So, alles zurück gestellt auf DavisVantage v0.8d...
Externe Stromversorgung raus genommen.
Nun entspricht der Aufbau 99% deines Schaltplanes.
1% ist der BMP280 der bei dir nicht eingezeichnet ist.
Konnte diesmal alles eingeben, nur der RMF69CW wir immer noch nicht erkannt.
siehe serielles Output.
Anbei mein Aufbau...
Bitte schau ihn dir das Foto genau an, ob ich evtl. war übersehen habe.
Habe ein Fehler entdeckt.
Die Stromversorgung vom RFM69 hing nach Masse.
Nun kommt folgende serielle Ausgabe im Sekundentakt.
Danke
Dirk
PS: RMF69 wurde jetzt erkannt.....ob alles läuft zeigt sich Später
Habe nach einer Stromunterbrechung wieder das Problem.
Die 4 Pins gezogen...bootet
Bilder Anbei
Huch, wo ist dein voriger Beitrag geblieben?
habe ich gelöscht, da ich dachte dein PS überlesen zu haben.
D5 SCK
D6 MISO
D7 MOSI
D8 CS
es sieht so aus, als ob D0 SCK hat. knipps mal so, das die Beschriftung von D5 - D8 wie normaler Text zu lesen ist und darüber die 4 Kabel zu sehen sind (Reihe Breakout, Kabel + Wemos-Pins).
Bilder waren Falsch...berichtigt
Durch Hektik versteckt.... >:(
zieh mal nur D8 raus. Strom weg und wieder ran.
Bootet
D8 wieder ran und den Reset-Button drücken. Schauen ob er bootet. Dann Strom weg und wieder ran.
probier auch mal 10k als pulldown an D8.
Reset sofort kein boot mehr. Das gleiche nach der Stromunterbrechung....blaue LED blinkt taktisch.
Ich würde sagen ich kontaktiere dich morgen via PN und wir könnten in Skype/Whatsapp weiter machen.
Wenn du nichts da gegen hast....
PS: 10 K PullUp nach 3,3V funzt
Fährt aber nicht hoch.....nicht in der Fritte
ich bin verwirrt. pullup an gpio15/D8? da versucht der Wemos von einer SD-Card zu booten.
pulldown wäre hier richtig.
10 k pulldown reichen nicht...vorschlag?
1k ? oder 4,7k
Ich will hier nichts schrotten
hab im Netz was von 3k3 gelesen. also eher 4k7.
Kannst ja mal den Pegel messen mit 10k. Noch einen zweiten Wemos zur Hand?
was steht in der Klammer bei boot(x,y)?
Insgesamt habe ich 4 zur Hand.....
Hatte ja 3 erst bestellt.
An 2 muss ich noch die Stiftleisten löten....
Teste morgen mal alles durch.....melde mich dann.
Irgendwo muss ja der Teufel im System versteckt sein....kann ja nur an Fertigungstoleranzen liegen.
Wünsche dir erstmal eine gute Nacht....und Danke für den Einsatz.
In der Klammer steht jetzt
ets Jan 8 2013,rst cause:1, boot mode:(3,0)
Auf dem Foto oben boot mode:(3,7)
Jetzt noch einen probiert (3,3)
Sobald CS neu gesteckt wird, hört die Bootschleife auf. Aber der RMF69 ist nicht erkannt worden.
Alle Prozeduren die wir schon hatten, sind durchgespielt
Ein 4,7k Pulldown bringt es auch nicht.
Das gleiche Verhalten hatte ich übrigends mit dem NodeMCU der von dir Compiliert wurde.
Ich bekam ja den Sketch wegen eines Fehlers nicht compilliert.
Ich habe mal den aktuellen Sketch auf den Nano geflasht, auch dort wird kein RMF69 erkannt.
Wieder zurück zu 07e mit alten RFMxx Treibern....das funzt.
Wemos:
probier mal Zeile 44 in RFMxx.cpp zu auszukommentieren
// SPI.setClockDivider(SPI_CLOCK_DIV64);
und Zeile 7 in Vantage.h den Kommentar löschen
#define _WEMOS_DAVIS_SHIELD // just for special hardware required
oder die .bin-Datei aus dem Anhang
Nachtrag: welche Version von ESP8266 ist bei dir in der Boardverwaltung installiert?
OK VALUES BME280 0 1=21.90,2=937,3=53,
[NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280]
;)
Empfang startet nur nicht...habe erstmal nur die ISS ausgewählt
Auf initCommands keine Reaktion
Port 9001 ist richtig?
Der BMP280 ist in fhem initialisiert
Port 9001 ist der Debug-Port.
da kannst du auch Kommandos absetzen. Was kommt bei "s"?
[NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] stations:
0/1
#0: 0,0 a
packets: 0, lost: 0, resyncs: 0
In der seriellen Konsole abgesetzt....
Sohn kommt gleich, der kennt sich mit fhem besser aus......
Nutze eigentlich nur iobroker aber mit fhem Adapter....das funzt gut zusammen.
In iobroker nimmt man sich leider der Sache nicht an....dort gibt es einen JeeLink Adapter, aber der unterstützt die Davis nicht.
Was ist denn der normale Ausgabeport? 12345?
was sagt er zu "v"?
station löschen: 0,10s
discovery modus: 1D
v: [NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] config: 2b
0,0s
uptime: 00:01.17
....und nun wieder flashen angesagt. Weil es so schön ist.
Nicht mal mehr in der Fritte drin.
Wenn wir schon mal dabei sind, wie ist der Ausgabe Port für Fhem um ein Device anzulegen?
Bis Dato habe ich die 9001 drin...
Was ist mit dem 4,7 k pulldown. Soll er drin bleiben?
die Daten werden per UDP-Multicast gesendet.
im zip ist unter FHEM das Modul 36_KVPUDP.pm
gehört in den FHEM-Ordner (da liegt auch 36_KeyValueProtocol.pm)
in fhem
reload 36_KVPUDP
define myKVPUDP KVPUDP
wenn da Fehler kommen bzgl. fehlenden perl-Modulen, dann müssen die per apt-get nachinstalliert werden.
was ist mit dem discovery mode? der sollte alle 3 Stationen sehen können.
Super, Danke.
Bin derzeit nicht zuhause....
...geht wieder weiter wenn ich Heim bin.
Bin wieder dabei...
Hier die Ausgabe von initCommands 1D
[NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME
280] [NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] [Node
MCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] [NodeMCU.0.8d2
compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] [NodeMCU.0.8d2 compiled a
t Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] [NodeMCU.0.8d2 compiled at Aug 28 2
020 12:22:28 (RFM69 b:2) + BME280] [NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:
28 (RFM69 b:2) + BME280] [NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69
b:2) + BME280] [NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME
280] [NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] [Node
MCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] stations: 0/0
Vorher keine Stationen in der GUI angelegt.
Folgende Fehler kommen beim reload 36_KVPUDP
2020.08.30 12:27:47 1: PERL WARNING: Subroutine KVPUDP_Initialize redefined at ./FHEM/36_KVPUDP.pm line 45.
2020.08.30 12:27:47 1: PERL WARNING: Subroutine KVPUDP_Define redefined at ./FHEM/36_KVPUDP.pm line 70.
2020.08.30 12:27:47 1: PERL WARNING: Subroutine KVPUDP_Fingerprint redefined at ./FHEM/36_KVPUDP.pm line 115.
2020.08.30 12:27:47 1: PERL WARNING: Subroutine KVPUDP_Undef redefined at ./FHEM/36_KVPUDP.pm line 121.
2020.08.30 12:27:47 1: PERL WARNING: Subroutine KVPUDP_Ready redefined at ./FHEM/36_KVPUDP.pm line 134.
2020.08.30 12:27:47 1: PERL WARNING: Subroutine KVPUDP_DoInit redefined at ./FHEM/36_KVPUDP.pm line 147.
2020.08.30 12:29:57 1: reload: Error:Modul 36_KVPUDP deactivated:
Experimental keys on scalar is now forbidden at ./FHEM/36_KVPUDP.pm line 168.
2020.08.30 12:29:57 0: Experimental keys on scalar is now forbidden at ./FHEM/36_KVPUDP.pm line 168.
Der Aufbau ist nach wie vor nach deiner Schaltung mit Transistor. Nur der 4,7k Pulldown wurde wieder entfernt.
veraltete 36_KVPUDP.pm ausgetauscht (md5: 73d052df3de243459603cfca8e234ffc)
wenn initCommand = 1D, dann solltest du folgendes zu sehen bekommen
[NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] stations: 0/0
OK DISCOVERY NodeMCU 0 22=-76,
OK DISCOVERY NodeMCU 0 22=-75,
da du 3 Stationen hast, müssten hinter NodeMCU die jeweilige ID auftauchen. Es wird "nur" auf Kanal 0 gelauscht. Wenn da keine Nachrichten auftauchen, dann wird auch keine Station erkannt.
Fhem läuft.
....nicht anderes wie das vorige Post von mir, nur habe ich die letzten Zeilen rauskopiert.
...und es waren keine Stationen definiert.
Jetzt sind wieder 3 Stationen in der GUI eingetragen.
initCommands 1D bringt in der seriellen Konsole
[NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280]
stations: 0/3
#0: 0,0 a
#1: 1,1 a
#2: 2,4 a
packets: 0, lost: 0, resyncs: 0
In Fhem keine Reaktion auf 1D
"stations: 0/3" meint, dass er keine der Stationen sehen kann. Ggf. kommt der Interrupt auf gpio2 nicht an.
du kannst im GUI alle Stationen löschen. dann verbindest du dich zum Port 9001 auf dem ESP gibst folgende Befehle ein
v
s
1D
nach 1D wartest du 5 min, und postest dann bitte die Ausgabe aller 3 Kommandos.
initCommand brauchst du nicht zu setzen für KVPUDP, da das Modul mehr als 1 Endgerät verwaltet (list myKVPUDP; da steht dnn eine Liste von Peers).
Ich stehe jetzt auf dem Schlauch.
Wo bitte soll ich in fhem die Befehle eingeben und wo ist die Ausgabe....?
Sorry...fhem ist noch nicht so meins.....bin aber lernwillig.
Man muss das System erstmal durchschauen und kapieren.
Das war eigentlich der Grund, warum ich zu iobroker kam....
Wenn ich erstmal weiss wie es funzt, dann ist es eine Kleinigkeit.
Ich schreibe im Hintergrund mit und erarbeite mir eine eigene Doku....
Den Nano habe ich ja auch ans laufen bekommen.
Nur ist das hier wieder komplizierter.
Anderen Transistor mit höheren HFE auch schon probiert und die Widerstände auf 10K geändert. Keine Änderung.
9001 ist der Debug-Port am ESP.
z.B. mit putty verbinden: hostname ESP, port 9001, raw. Unter Terminal noch implizites LF for CR einstellen. Dann hast du eine serielle Schnittstelle über TCP/IP.
da kannst du die Kommandos eingeben und Ausgabe sehen.
Da habe ich wirklich auf dem Schlauch gestanden.
Es kann so einfach sein...wobei ich sehr viel mit Putty arbeite.(Enigma2)
v: [NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] config: 2b 0r
s: [NodeMCU.0.8d2 compiled at Aug 28 2020 12:22:28 (RFM69 b:2) + BME280] stations: 0/0
1D:
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=57,
OK VALUES BME280 0 1=20.00,2=949,3=57,
OK VALUES BME280 0 1=20.00,2=949,3=57,
OK VALUES BME280 0 1=20.00,2=949,3=57,
OK VALUES BME280 0 1=20.00,2=949,3=57,
OK VALUES BME280 0 1=20.00,2=949,3=58,
OK VALUES BME280 0 1=20.00,2=949,3=58,
OK VALUES BME280 0 1=20.00,2=949,3=58,
OK VALUES BME280 0 1=20.00,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=57,
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=57,
OK VALUES BME280 0 1=19.90,2=949,3=58,
OK VALUES BME280 0 1=19.90,2=949,3=57,
OK VALUES BME280 0 1=19.90,2=949,3=57,
OK VALUES BME280 0 1=19.90,2=949,3=57,
Habe länger als 5 Min. gewartet
entweder kommen keine Signale an oder der Interrupt vom RFM69 wird nicht erkannt (gpio2).
Der RMF69 empfängt mit der Antenne wie auf den Breadboards zu erkennen, am NANO einwandfrei.
Habe sie jetzt untereinander getauscht.
RSSi am Nano
Station normal eigentlich ein (-) davor >
0, 63dBm
1, 67dBm
2, 68dBm
Kann ich den Transistor durch eine Drahtbrücke ersetzen oder muss noch ein Widerstand in die gpio2 Leitung?
Also zwischen DI00 und gpio2....
Alle Steckbrücken sind auf Durchgang getestet.
den Transistor kannst du nicht entfernen, da er den Pegel von DIO0 invertiert. vor dem Collector und der Basis müssen Widerstände drin sein.
gib mal noch 3p ein. dann sollten die Rohdaten aller empfangenen Nachrichten angezeigt werden (auch mit Checksummenfehler).
Ich habe ebend eine Steckbrücke gewechselt, die war unten im Board durch die Biegerei abgebrochen.
Dann hatte ich auf einmal
OK DISCOVERY NodeMCU 0 22=-63,
Also die dritte Station. Ich sehe auch, das er Empfängt an der blauen LED am Wemos.
Nur seriell kommt nur der BMP280
3p
OK DIAGNOSTIC NodeMCU 22=-98,255=04-20-01-09-24-01-02-08-04-08,
OK DIAGNOSTIC NodeMCU 22=-100,255=44-69-1b-29-10-01-40-14-d1-e8,
OK DIAGNOSTIC NodeMCU 22=-100,255=00-80-00-00-02-08-08-e0-20-00,
OK DIAGNOSTIC NodeMCU 22=-99,255=60-10-04-30-00-0c-00-44-10-08,
OK DIAGNOSTIC NodeMCU 22=-102,255=ef-8e-25-fb-bd-fd-9d-de-2e-a4,
OK DIAGNOSTIC NodeMCU 22=-100,255=18-45-40-40-88-1a-11-34-10-60,
OK DIAGNOSTIC NodeMCU 22=-98,255=00-20-41-38-00-82-00-42-94-01,
OK DIAGNOSTIC NodeMCU 22=-99,255=45-00-80-00-00-10-05-20-2c-00,
OK DIAGNOSTIC NodeMCU 22=-99,255=02-75-00-04-00-1a-00-08-40-00,
OK DIAGNOSTIC NodeMCU 22=-99,255=00-90-00-00-10-00-00-00-08-40,
OK DIAGNOSTIC NodeMCU 22=-100,255=e5-30-45-04-d7-10-41-42-81-1e,
OK DIAGNOSTIC NodeMCU 22=-102,255=80-04-00-08-00-00-08-00-00-00,
OK DIAGNOSTIC NodeMCU 22=-101,255=80-04-40-6c-02-18-11-02-11-a0,
Alles da...mit 1D
OK VALUES BME280 0 1=20.80,2=950,3=57,
OK DISCOVERY NodeMCU 1 22=-65,
OK DISCOVERY NodeMCU 0 22=-62,
OK DISCOVERY NodeMCU 2 22=-70,
OK DISCOVERY NodeMCU 1 22=-66,
OK DISCOVERY NodeMCU 0 22=-63,
OK DISCOVERY NodeMCU 1 22=-65,
OK DISCOVERY NodeMCU 0 22=-62,
OK DISCOVERY NodeMCU 2 22=-69,
OK DISCOVERY NodeMCU 1 22=-66,
OK DISCOVERY NodeMCU 0 22=-63,
OK DISCOVERY NodeMCU 1 22=-65,
OK DISCOVERY NodeMCU 0 22=-62,
geht doch
Zitat von: habeIchVergessen am 28 August 2020, 12:24:11
Wemos:
probier mal Zeile 44 in RFMxx.cpp zu auszukommentieren
// SPI.setClockDivider(SPI_CLOCK_DIV64);
und Zeile 7 in Vantage.h den Kommentar löschen
#define _WEMOS_DAVIS_SHIELD // just for special hardware required
oder die .bin-Datei aus dem Anhang
Ja funzt jetzt, ;)
aber folgendes habe ich gemacht und wollte meinen Code anpassen auf die letzte Version (DAVIS)
Das aus dem Zitat passt nicht und ist für mich Widersprüchlich. Oben soll ich die Zeile mit dem Shield löschen
gleichzeitig schickst du mir eine *.bin mit Shield.
Das ist die, die derzeit auf dem Wemos läuft.
Das anpassen, wie geschrieben geht nicht. Ich habe immer eine blinkede blaue LED am Wemos.
Würdest du mir bitte alles noch mal geändert anhängen?
Wo gebe ich die Altitude ein....Initscommands kann ich nirgends eingeben.....
Danke
PS: Es werden irgendwelche Zahlen angelegt....man kann sie löschen werden aber nach einem Reboot wieder angelegt?
Kann man das unterbinden?
siehe Foto
in meiner Schaltung wird per Transistor das Interrupt-Signal von DIO0 invertiert, da gpio0 und gpio2 beim Booten vom ESP8266 high sein müssen.
4 Pins sind für SPI weg, jeweils 2 für I2C und die serielle Schnittstelle. da bleiben nicht mehr so viele übrig, die den Interrupt empfangen können.
Deshalb wird zwischen Arduino und ESP8266 unterschieden (_WEMOS_DAVIS_SHIELD), auf welchem Pin mit welchem Flank-Wechsel der Interrupt erkannt wird.
Die Änderung in RFMxx.cpp betrifft "nur" die Geschwindigkeit, mit der über SPI kommuniziert wird. Scheinbar hat dein RFM69 mit 80MHz/64 Probleme.
Quellcode reiche ich später nach.
zu den Readings, deren Name einen Zahlenwert ist:
Das ist ein FHEM-Problem, da beim initialen Anlegen erst die Readings und anschließend die Internals (inkl. Mapping zwischen Zahl und Text) geschrieben werden. Das ist schätzungsweise ein sehr zentraler Punkt und müsste von rudolfkoenig (https://forum.fhem.de/index.php?action=profile;u=8) erledig werden.
Für zusätzliche Optionen (ID vom BME/BMP, Altitude, etc.) fehlt noch das GUI.
Die LED am Wemos kannst du nicht ausschalten, da immer blinkt, wenn etwas über die serielle Schnittstelle geht.
Danke,
Mit blinken der LED meine ich den Sekundentakt...
Das Problem hatte ich doch schon oben irgendwo beschrieben.
Nicht die Empfangsquittierungen....die ich am Nano auch habe.
So wie du das beschrieben hast, ist meine Schaltung auch aufgebaut und sollte identisch sein.
Ich will und wollte auch die Wemos LED nicht abschalten!?
LED: dann habe ich dich falsch verstanden. Bei mir blinkt sie ca. alle 2-3s mit einer Station. mit 3 Stationen könnte das schon im Sekundenbereich liegen.
anbei die Sourcen für v0.8e (BMP/BME-Optionen im GUI)
Hi,
wir schreiben anscheinend dran vorbei.
Mit Sek. Takt meine ich die Bootprobleme, die hier immer noch auftreten.
Der Wemos versucht zu booten und das im Sekundentakt.
Du hast mir am 28.08.20 folgende "NodeMCU v0.8d (Wemos D1 mini + Davis Shield).bin" geschickt.
Damit geht es....
Aber wieder nicht der angehängte Sketch....
Als Board nehme ich in Arduino "weMos D1 R1".
Sind noch irgendwelche Einstellungen von nöten....vielleicht liegt es ja daran.
welche Version vom ESP8266 SDK nimmst du? ich benutze Version 2.4.1 (WeMos D1 R2 & mini)
Arduino IDE nehme ich 1.6.13. 1.8.12 + .13 gehen auch.
Super das war es.
Höhe eingeben geht auch...
Arduino ist die aktuelle Version.
SDK hatte ich 2.7.4
Das war der Fehler.
....jetzt runter auf 2.4.1
Nochmals vielen Dank....
Eine Bitte hätte ich noch.
Kannst du hinter den Lufrdruck noch eine Kommastelle einfügen.
So wäre es mit der Konsole identisch.
Kannst mir aber auch die Codezeile posten. Dann ändere ich das nur bei mir.
Danke
Gibt es was neues vom Mapping....die Zahlen die immer wieder angelegt werden?
bzgl. Mapping habe ich nichts unternommen. da müssen sich andere drum kümmern.
kannst du in FHEM aber leicht löschen
deletereading BM[PE][126]80 \d+(\.[A-Za-z0-9]+){0,1}
deletereading KeyValueProtocol_.* \d+(\.[A-Za-z0-9]+){0,1}
anbei die Sourcen (Luftdruck mit Nachkommastelle)
Hallo,
bis jetzt läuft soweit alles Super.
Wärst du daran intressiert am Wemos ein OLED Display zu integrieren?
Ich schon....möchte alles absetzen und habe dann kein Laptop bzw. PC in der Nähe.
Es wäre dann schön an Ort und Stelle mal den Status abzurufen....
Zur Info: Im LaCrosseGateway werden Displays und Oleds unterstützt.
Via ESPEasy läufts auch....siehe Anhang
Dort kann man einen Taster integrieren um das Display zu aktivieren.
Das schaltet sich nach einer voreingestellten Zeit wieder aus.
Was meinst du dazu?
btw....habe jetzt den Mini Pro genommen um eine WLan Antenne abzusetzen.
ich bin skeptisch. I/O-seitig wird für SPI schon knirsch. i2c würde noch gehen.
Dann schlage ich i2c vor....
Bei SPI müsste das 0.96 OLED umgebaut werden...
...so stehts in der LacrosseGateway Wiki....
Meins unterstützt kein SPI...
https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x#Inbetriebnahme_von_OLED-Display
Am ESPEasy ist es auch via i2c angeschlossen.
Ist scheinbar an Akta gelegt.....
Schade, war auch nur eine Frage und Anregung.
Dann mache ich mir jetzt eine Platine fertig....hatte ja noch gewartet.
ich habe mir die Sourcen noch nicht angeschaut.
was ich erwarte:
- das Renderen der Anzeige passiert nicht auf dem ESP
daraus ergibt sich:
- die passenden Schnittstellen in FHEM sind zu identifizieren (Ausgabe)
- ESP brauche die Möglichkeit, die Daten entgegen nehmen zu können (Schnittstelle passend zu den Modulen aus vorangegangenem Schritt)
- eventuelle Benutzereingaben müssen nach FHEM, damit das Renderen getriggert wird (wer nimmt die entgegen und wie wird das durch die Ausgabe verarbeitet)
wenn du möchtest, kannst du hier gerne unterstützen.
Hi....
...ich möchte dir gern dabei helfen.
Jetzt meine Frage, warum muss das Rendern in FHem vorgenommen werden?
Wichtig wäre das der Chipsatz SSD1306 mit unterstützt wird.
Du hast so ein super GUI erstellt, lässt sich nicht dort ein Untermenü für das OLED erstellen?
Dort werden die Einstellungen gemacht wie:
Enable OLED:
I2C Address:0x3C (60) oder 0x3D (61) 60 ist default
Rotation: Rotation oder Normal
Display Size: hier z.B. 128x64
Es passen wohl auf eine Seite 8 Lines
Einstellbar was man als ertes haben möchte...
z.B.
1.Temp :[BMP280#Temperature]°C
2.Wind:[KeyValueProtocol_DAVIS_2#Windspeed]kmh
usw.
Mit einstellbaren Blättern der Seiten.
Einen einstellbaren Display Timeout von 0 (Aus) - z.B. 60 min.
Zudem noch einen zugewiesen Taster auf einen freien GPIO
Damit man das Display wieder aktivieren kann
und noch einen einstellbaren Seiten Interval von z.B. 0 - 60 sec
Vielleicht hilft es dir bei der Realisation
Ich würde FHEM aussen vor lassen und den ESP das überlassen.
So braucht man zur Abfrage weder einen PC, Laptop oder der gleichen.
Meine Bridge soll dann mal auf dem Dachboden....da habe ich solche Geräte nicht.
Möchte aber mal aktuelle Daten abfragen....mehr eigentlich nicht.
Hoffentlich habe ich nicht was vergessen.... :)
Grüße
Dirk
PS:....schreib mich einfach an, wo ich dir behilflich sein kann.
das Berechnen der Pixel (Rendern) sehe ich nicht auf dem ESP. kenne keine Library, die das machen würde. Wenn du da was findest, dann schaue ich es mir gerne an.
Ok,
habe eh keine Ahnung davon.....
Nur ESPEasy kann es ja auch....alles auf dem ESP.
Die Sourcen davon kannste dir im Netz herunterladen....
Im Anhang was ich auf der Schnelle gefunden habe
Vielleicht passt was davon....
beim LaCrossGateway sind es die OLED*-Dateien. Wenn ich es richtig verstehe, steht in OLEDFont.h pro Buchstabe eine Pixelmatrix. Pro Font-Size gibt es mehrere Definitionen.
Hallo,
ich hätte da mal eine generelle Frage:
Kann die hier vorgestellte Lösung mit dem JeeLink und dem entsprechenden Sketch auch übers Netz betrieben werden.
Im Thread und in der Commandref konnte ich keine Hinweise finden.
Ich habe an meinem Serverstandort keinen Funkempfang und müsste den Stick "auslagern".
Beim CUL habe ich von der Möglichkeit gelesen dann über ser2net und einem Port zuzugreifen.
Danke und Gruß
plinepa
Schaltplan (https://forum.fhem.de/index.php/topic,44092.msg1081237.html#msg1081237) für einen Wemos findest du im verlinkten Post
Mal was neues von mir...
Display habe ich an Akta gelegt....bei so großen Intresse.
Hallo,
ich wärme das Thema mal eben wieder auf. Ich möchte eine alte Vantage pro 2 an mein FHEM anbinden, da der original-Empfänger "gestorben" ist. Funktioniert das ganze wohl auch mit dem aktuellen Jeelink V3c aus dem DigitalSmarties-Shop? Zitat:
. It contains Atmel's ATmega328p AVR microprocessor, HopeRF's RFM69CW wireless radio module and a branded FT232R USB interface chip. The processor is pre-flashed with the OptiBoot loader (compatible with the Arduino Uno) and the RF12demo sketch.
Oder gibt es alternative Methoden die Daten vom Vantage Pro 2 Sensorenset aufzuzeichnen?
Danke für die Hilfe!
Zusch
sollte funktionieren
Vielleicht kann jemand helfen:
Werden mit dem Modul "nur" die Standardwerte (aus Post 1) der Vantage Pro (2) oder Vantage VUE empfangen oder gehen auch die Erweiterungen wie bspw. die Wireless Leaf & Soil Moisture/Temperature Station?
Danke vorab und schönen Abend.
sollte gehen. habe ich nicht probiert.
Hi,
ich habe mehre Davis ISS Einheiten.
Innerhalb des Davis Sketches sehe ich die auch:
raw 0r 1D [DAVIS.0.8e compiled at Sep 5 2020 16:30:03 (RFM69 b:2)] [DAVIS.0.8e compiled at Sep 5 2020 16:30:03 (RFM69 b:2)]
OK DISCOVERY DAVIS 7 22=-67,
OK DISCOVERY DAVIS 0 22=-69,
OK DISCOVERY DAVIS 7 22=-68,
OK DISCOVERY DAVIS 0 22=-69,
OK DISCOVERY DAVIS 7 22=-67,
OK DISCOVERY DAVIS 0 22=-69,
Bei der Initialisierung auf ID0 (bzw. 1 innerhalb Davis-Notation) sehe ich Daten:
0,0s r
OK VALUES DAVIS 0 20=4,22=-72,21=ok,4=0.00,5=211,8=109,
Bei ID7 (bzw. 8) bekomme ich nichts. Es ist ebenfalls eine Davis VP2 ISS Einheit.
7,0s r
Hat jemand eine Idee?
Danke vielmals.