Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Spiff]

Hi,

die wiki-Seite zum Sensor ist hier:
http://www.fhemwiki.de/wiki/Universalsensor

Ich habe es gestern endlich hinbekommen, die Sensoren zu peeren.
Zur Analyse empfiehlt sich das hmInfo-Modul.

Es geht so:
- Sensor und Regler mit fhem pairen.
- den Sensor muss man momentan (FW 0.14) evtl. mehrmals (2-3x) pairen, bis alle dargestellten Fehler bei set hmInfo configCheck beseitigt sind.
- set (sensor) peerChan 0 (Regler_Weather) single peert den Sensor mit dem Weather-Kanal des Reglers.
- am Sensor wieder mehrmals (2-3x) den config-Knopf drücken.
- am Regler muss man keinen Anlernmodus ausführen. Wenn man das macht, wird er sofort beendet und keine Statusnachricht angezeigt. Etwas verwirrend.
- wenn noch Register-Fehler im set hmInfo configCheck angezeigt werden, hilft ein set (Regler) getConfig und ggf. eine Beschleunigung der Übertragung der Daten für Ungeduldige mit set (Regler) burstXmit
- Als Check, ob alles geklappt hat, müssen in set hmInfo peerXref beide Richtungen dargestellt sein: Sensor => Regler und Regler => Sensor
- weiterer Check: im Regler_Weather und Sensor muss das Attribut peerIDs 00000000,21FF3401 angezeigt sein (die zweite ist die ID des jeweils anderen Gerätes)
- weiterer Check: die Sensor-LED blinkt jetzt 3x bei der Übertragung
- weiterer Check: die measured-temp des Reglers muss jetzt der des Sensors entsprechen.

Und genau da musste ich leider feststellen, dass die Übertragung der Temperatur bei mir nicht zuverlässig funktioniert.
Der Regler wechselt immer zwischen seiner eigenen und der des Sensors hin und her.
Ich habe als Test die Sensoren in den Kühlschrank gelegt. Die Entfernung zum Sensor und HMLAN ist ca. 3m.
Daher vermute ich eher keinen "Hardware-Übertragungsfehler" durch schlechten Empfang.
Hat jemand ähnliche Erfahrungen gemacht?

Anbei ist eine Aufzeichnung, aus der man erkennt, wie die Temperatur (rot) hin und wieder die des Reglers annimmt. Wenn dann wieder die Sensor-Temperatur des Kühlschranks angezogen wird, greift die Fenstererkennung und stellt die Soll-Temp (blau) auf 12°C. Der Aktuator (grün) fährt fleißig hin- und her.

Dann noch ein Bug (oder Feature) im Regler: Sensoren wieder aus dem Kühlschrank genommen, Fenstersymbol erlischt, Soll-Temperatur bleibt bei 12°C...

Viele Grüße
Spiff

[moonsorrox]

die wiki-Seite zum Sensor ist hier:
http://www.fhemwiki.de/wiki/Universalsensor

wenn du mich meinst...!
Ja ich weiß das (habe es als Link abgespeichert)  , aber ich wollte nur darauf hinweisen, das wenn hier jemand sucht, er meistens nicht nach Universalsensor sucht... denke ich..!! 

[Gernott]

Hat jemand ähnliche Erfahrungen gemacht?

Ja: http://forum.fhem.de/index.php/topic,34948.0.html

Gruß
G.

[Dirk]

Hallo Zusammen,

Zuerst ein Versuch ohne Bootloader per ISP-Programmer über die Arduino IDE, dabei wird der Bootloader beim programmieren entfernt. (Soweit ich das weiss)

Das ist korrekt.

Danach ein Versuch mit dem Standart Arduino Bootloader.

Der Standart Bootloader wird keine Seriennummer usw. zurück liefern. Da musstest du eine Spezielle Firmware compilieren und flashen die diese Daten schon enthält.

Ich glaube, die Frage müsste eher lauten, ob das jemand überhaupt schon einmal gemacht hat.

Das hatte ich auch noch nicht getestet da ich an diese Möglichkeit noch gar nicht gedacht hatte.
Daher funktioniert das aktuell offensichtlich nicht.

Hallo Holgi,
Oder Du baust um auf OTA bootloader  . Was das bedeutet, ist in betateilchens Anstrengungen auf mehreren Seiten (ab S. 108 ff) nachzulesen.

Ich denke das war eher die Ausnahme das das bei Betateilchen so kompliziert war.

ich hatte das Problem mit der fehlenden Luftdruckanzeige ja gemeldet. Teilweise kann ich jedoch Entwarnung geben: Der Luftdruck wird auch mit der neuesten CCU2-Firmware 2.13.7 korrekt angezeigt. Da ich das Sensor-Addon nicht auf die CCU2 aufspielen konnte, hatte ich dies manuell gemacht: Auf dem Windows-PC das AddOn-File entpackt und die Files /firmware/rftypes/* per scp auf die CCU2 kopiert. Danach wurde der Luftdruck nicht angezeigt. Ich habe das Ganze jetzt noch mal wiederholt, aber das Addon-tar.gz-File direkt auf der CCU2 entpackt und dann die Files in die richtigen Ordner kopiert. Nun wird auch der Luftdruck richtig angezeigt. Ich vermute, dass beim Entpacken auf dem Windowsrechner ein dos/unix-Formatproblem aufgetreten ist (CRLF), und das xml-File dann von der CCU2 nicht mehr richtig gelesen wurde.

Es bleibt also nur noch das Problem, dass die CCU2 das Addon nicht installieren will (mittels "Zusatzsoftware installieren").

Ah, Danke für den Hinweis.
Ich schaue mir das Addon noch mal an, warum sich das im Moment nicht installieren lässt.

Mein Ziel ist es die 0.14 über einen Raspberry PI (ohne USB-UART-Adapter) auf die Sensoren zu bekommen.

Theoretisch sollte das auch funktionieren. Das hier könnte da eine Anlaufstelle sein:
http://www.deanmao.com/2012/08/10/uploading-sketches-to-the-arduino-on-the-pi/

Und genau da musste ich leider feststellen, dass die Übertragung der Temperatur bei mir nicht zuverlässig funktioniert.
Der Regler wechselt immer zwischen seiner eigenen und der des Sensors hin und her.
....
Hat jemand ähnliche Erfahrungen gemacht?

Ja, das ist noch ein bekanntes Problem.
Allerdings kann ich das bei mir aktuell noch nicht nachvollziehen.
Daher währ es schön, wenn du da als Tester mit zur Verfügung stehen kannst



Viele Grüße
Dirk

[Mr. P]

Ja, das ist noch ein bekanntes Problem.
Allerdings kann ich das bei mir aktuell noch nicht nachvollziehen.
Daher währ es schön, wenn du da als Tester mit zur Verfügung stehen kannst

Ich glaube, da stehen dir auch ein paar Leute mehr zur Verfügung.

[Gernott]

Ich glaube, da stehen dir auch ein paar Leute mehr zur Verfügung.

Na sicher. Am besten, Dirk läßt uns mal wissen, was er genau braucht, und wir testen. Ich hatte das Peering nach einigen Versuchen wieder aufgehoben, da es nicht ging.

Gruß
G.

[Dirk]

Am besten, Dirk läßt uns mal wissen, was er genau braucht, und wir testen. Ich hatte das Peering nach einigen Versuchen wieder aufgehoben, da es nicht ging.

Am Besten währ folgendes:
Die Aktuelle Version der FW (0.15) auf einem Sensor zum Testen installieren. Hier sehen die Debugausgeben wieder besser aus.
Aktuelle muss man die selber kompilieren. Kann ich aber auch zur Verfügung stellen. Und dann die Debugausgaben vom Sensor über den UART eine längere Zeit am besten parallel zu FHEM aufzeichnen.
Da hoffe ich was ableiten zu können.

Viele Grüße
Dirk

[Dirk]

Ich habe die v0.15er firmware-files in die git Masterbranch mit eingecheckt.

Damit sehen die Debugausgaben wieder besser aus.
Jetzt warte ich auf Logs von gepeerten Thermostaten

Viele Grüße
Dirk

[Mr. P]

Und dann die Debugausgaben vom Sensor über den UART eine längere Zeit am besten parallel zu FHEM aufzeichnen.
Da hoffe ich was ableiten zu können.

Ok, muss mir leider erst am Dienstag Kabel besorgen... aber das schaffen wir auch noch.

[Gernott]

Am Besten währ folgendes:
Und dann die Debugausgaben vom Sensor über den UART eine längere Zeit am besten parallel zu FHEM aufzeichnen.

Dazu habe ich noch eine Frage. Was genau meinst Du damit? Offenbar nicht das Mitschneiden in FHEM?

Gruß
G.

[Dirk]

Das Mitschneiden der Logs in FHEM von Sensor und Thermostat ist der eine Teil.
Das Andere ist das Mitschneiden der Debugausgaben des Sensors an dessen serieller Schnittstelle.

Die Einstellungen  vom UART hier sind übrigens 57600 Baud, 8 Bit, Parity None.

Sensor -> UART (RPI oder UART-USB-Adapter)

Code Auswählen Erweitern


Sensor -> RPI/Adapter
TX     -> RX
GND    -> GND


Beim Sensor ist dazu die untere Pinleiste zu verwenden (über dem Batteriehalter) und gezählt von Links
1: TX
4: GND

Der Pegel wird vom Sensor vorgegeben (3,3 V)
In dieser Richtung kann der Sensor so daher auch an einen UART angeschlossen werden der mit 5 V arbeitet.

Viele Grüße
Dirk

[Gernott]

Das Andere ist das Mitschneiden der Debugausgaben des Sensors an dessen serieller Schnittstelle.

Das hatte ich befürchtet. So etwas übersteigt meine aktuellen Möglichkeiten. Gibt es dazu irgendwo eine Anleitung? Man müßte z.B. noch einen Raspi anschließen (Pegel?) und mit einem Terminalprogramm mitschneiden, nehme ich an. Einen USB-UART Konverter habe ich leider nicht.

Gruß
G.

[Dirk]

Ich habe es unten im Post mal aktualisiert.
Es reichen 2 Leitungen
Sensor -> UART (RPI oder UART-USB-Adapter)

Man müßte z.B. noch einen Raspi anschließen (Pegel?) und mit einem Terminalprogramm mitschneiden, nehme ich an.

Ja, genau. Das würde gehen

Viele Grüße
Dirk

[Gernott]

O.k., das könnte ich mal probieren. Der Sensor wirft kontinuierlich Daten auf der Schnittstelle aus oder muß man das irgendwo setzen?

Ergänzung:
Habe gerade in der Bastelkiste einen Prolific USB-serial-Konverter (7ST-DH-005) gefunden. Der müßte doch dafür gehen, oder?


Gruß
G.

[Dirk]

Nein, das Debug ist bei v0.14 und v0.15 aktuell immer an. Bei 0.15 halt in besser lesbarer Form. Daher bitte diese Version zum debuggen nehmen.
Bei jedem Senden/Empfangen und jeder Aktivität also auch Configtaste-Drücken gibt es ein entsprechende Debug-Ausgabe. Auch beim "Einschalten".

Wenn burstRx gesetzt ist, dann bleibt der Sensor aktuell übrigens dauerhaft an. Was sich dementsprechend auf den Batterieverbrauch auswirkt.
Allerdings sieht dann im Debug den Kompletten Funkverkehr aller HM-Geräte in der Nähe.
Daher bei den Tests burstRx am besten aus lassen. Ansonsten wird das zu viel.