JeeLink v3c/ESP8266 zur Einbindung von Davis Vantage

habeIchVergessen · 08 August 2016, 22:48:02

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

Code Auswählen


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.

StefanStrobel · 09 August 2016, 22:01:20

Vielen Dank schon mal.
Läuft es bei Dir denn auf einem Jeelink 3c mit den Änderungen?
Bei mir kommt im Terminal nur

Code Auswählen


[DAVIS.0.5 (RFM69 b:2)] 
INIT DICTIONARY

Das Dictionary selbst fehlt ...

Gruss
Stefan[/code]

habeIchVergessen · 09 August 2016, 22:21:54

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.

habeIchVergessen · 10 August 2016, 14:23:15

Zitat von: StefanStrobel am 08 August 2016, 20:26:00
anbei ein paar Rohdaten.

Code Auswählen


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.

habeIchVergessen · 10 August 2016, 22:16:19

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?

StefanStrobel · 10 August 2016, 23:04:51

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

habeIchVergessen · 11 August 2016, 00:39:07

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.

StefanStrobel · 14 August 2016, 17:24:33

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

habeIchVergessen · 15 August 2016, 23:29:52

Werden Daten sinnvoll empfangen (exkl. Berechnung)?
Welche Version der IDE benutzt du? Ich verwende 1.6.6.

StefanStrobel · 17 August 2016, 17:37:14

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

habeIchVergessen · 17 August 2016, 19:29:32

ich habe alle Dateien (exkl. ino) in einem Lib-Verzeichnis, da ich mehrere Sketches habe, die darauf zugreifen.

StefanStrobel · 20 August 2016, 21:32:48

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:

Code Auswählen


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:

Code Auswählen


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

StefanStrobel · 20 August 2016, 22:55:47

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

habeIchVergessen · 31 August 2016, 22:03:51

Sketch v0.7 (Anpassungen von StefanStrobel bzgl. Berechnung SoilTemperature und SoilMoisture teilweise übernommen).

StefanStrobel · 02 September 2016, 16:37:14

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