Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Pjg]

Ich Probier mal Knopf gedrückt halten beim Batterie einlegen.

[Dirk]

Hallo zusammen

Dirk, woher beziehst Du die Gehäuse aktuell? Ich werde wohl eins nachkaufen müssen.

Das Gehäuse hab ich von TME. Bei ELV gibt es das Gehäuse auch: http://www.elv.de/industrie-aufputz-gehaeuse-ip65-modell-g201c.html

kann man eigentlich irgendwo die Zeit zwischen den einzelnen Übertragungen der Werte einstellen?
Bei mir werden die Daten alle 3 min übertragen, alle 6 min würde mir im hinblick auf Batterielaufzeit auch reichen.

Aktuell nur im Code. Das Feature steht aber in meiner ToDo-Liste.

ich hätte  Interesse an zwei Universalsensoren.

Hab dir eine PM geschickt.

Wie ging das noch. Ich hab schon x mal den Knopf am Sensor gedrückt.
Und hmpairforsec 600 am CUL hab ich auch schon gemacht.

So ist der korrekte Weg. Aber auch ohne Peering sendet der Sensor Werte. Dann an Broadcast.
So wie es bei dir aussieht bekommst du aber gar keine Werte übermittelt.
Kannst du RAW-Werte vom Sensor in FHEM sehen?

Ich Probier mal Knopf gedrückt halten beim Batterie einlegen.

Damit startet der Bootloader. Das ist also nur beim Update notwendig.

Blinkt die LED nach dem Drücken der Config-Taste

Gruß
Dirk

Edit: falscher Link

[Pjg]

Ja, wenn ich drucke blinkt es

[Dirk]

Schau mal ins Eventlog. Dann sollte ein Eintrag beim Drücken kommen.
Ebenso beim regulärem Senden der Daten Entweder alle 2-3 Min.
oder direkt nach dem Batterieeinlegen.
Poste mal die Ausgabe vom Eventlog mit den Daten des Sensors

[Pjg]

Dauert. Hab die Handwerker im Haus. Wo ist das Eventlog?

[Dirk]

Ok. heisst "Event Monitor". In FHEM unten in der Navigation
Bei mir unter http://<meineIp>:8083/fhem?cmd=style%20eventMonitor

[Pjg]

Beim drücken kommt das

[Pjg]

Und das beim senden. Kommt irgendwie schon was, nur nicht die Helligkeit. Temp. Ist nicht bestückt

[Pjg]

Das

[Dirk]

Ok, Temperatur und Feuchte werden übertragen. Ich war nur Irritiert, dass bei deinen vorherigen Screenshots da auch 0 stand.
Du kannst zwar nochmal probieren die 0.14 oder 0.15er Firmware zu flashen. Sieht für mich aber nach einem Defekt aus. Das muss ich wohl reparieren / austauschen.
Falls das nach dem Update nicht funktioniert, schreib mich am besten per PM an.

Viele Grüße
Dirk

[Pjg]

Nein. Das ist der innensensor
Es geht um den aussen. Der hat nur einen helligkeitssensor.

[Dirk]

Ah, ok. Dann bin ich wohl in der Zeile verrutscht.

Eine Idee habe ich noch. Du hast nicht zufällig die Version der 0.15er Firmware geflasht die experimentell für den Ultraschallsensor gedacht ist?
Bei der ist der Helligkeitssensor deaktiviert.

[Pjg]

Nein. Ist 15 aber hat ja den ganzen Sommer funktioniert

[Linef]

Hallo,

ich bin gerade dabei, einen eigenen Raumtemperatursensor analog dem Universalsensor zu bauen - nur anderer Sensor.
Das Ganze soll zum Know-How-Aufbau für weitere HM-Projekte dienen.

Ursprünglich habe ich mit der NewAskSin-Lib angefangen und das Peering mit einem HM-CC-RT-DN getestet - allerdings
hatte ich nur sporadische Datenübertragungen. Danach bin ich auf die alte AskSin-Lib zurück gegangen - gleicher (Miss-)Erfolg.
Zuletzt habe ich den Original-Code vom Universalsensor verwendet, da hier ja (ich hoffe mal, das stimmt) das Peering
funktioniert. Die Abfragen der Sensoren habe ich mit der Rückgabe von Dummy-Werten "gebrückt".
Aber auch hier mag sich nach dem Peeren mit dem RT-DN keine dauerhafte Datenkommunikation einstellen...

Ich habe auch als eigene HM-ID die aus diesem Thread genommen: https://forum.fhem.de/index.php/topic,17485.0.html
Die Wartesequenzen ("Slots") kommen auch entsprechend, aber wenn mal eine Kommunikation zum RT-DN funktioniert hat,
die nächsten Datenübertragungen funktionieren dann wieder nicht.

Weiterhin habe ich auch festgestellt, daß wohl durch einen Compilerfehler (oder sonstigen Bug / Überschreiber in der Lib)
die Meßdaten nicht normal gesendet, sondern geburstet werden.
In diesem Falle funktioniert die Kommunikation mit dem RT-DN dauerhaft.
Das ist aber nicht das, was ich will. Wenn ich den Burst hart abschalte, dann geht's nur noch sporadisch.

Hier mal ein Protokoll:

Code Auswählen Erweitern

Starting sketch...
freeMem: 995 byte
Device type from PROGMEM: F1 01
Serial from PROGMEM: 48 42 30 44 65 66 61 75 6C 74
Addresse from PROGMEM: 1F 4C 66
powerMode: 3
Config changed. Data:  (L:0)
lowBatLimit: 16
ledMode: 1
burstRx: 0
transmDevTryMax: 3
altitude: 0
Slot=158, dst=159786, HMID=66 4C 1F 00, cnt=0 (M:1038)
<- 14 00 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1052)
<- 14 00 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1751)
<- 14 00 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2451)
-> NA  (M:3149)
Slot=144, dst=304276, HMID=66 4C 1F 00, cnt=1 (M:160028)
<- 14 01 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:160045)
<- 14 01 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:160743)
<- 14 01 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:161444)
-> NA  (M:162142)
Slot=130, dst=434517, HMID=66 4C 1F 00, cnt=2 (M:304519)
<- 14 02 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:304535)
<- 14 02 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:305234)
<- 14 02 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:305934)
-> NA  (M:306632)
Slot=179, dst=614241, HMID=66 4C 1F 00, cnt=3 (M:434743)
<- 14 03 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:434759)
-> 0A 03 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:434907)
Slot=165, dst=779448, HMID=66 4C 1F 00, cnt=4 (M:614450)
<- 14 04 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:614464)
<- 14 04 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:615162)
<- 14 04 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:615863)
-> NA  (M:616561)
Slot=150, dst=930442, HMID=66 4C 1F 00, cnt=5 (M:779694)
<- 14 05 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:779711)
<- 14 05 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:780409)
<- 14 05 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:781110)
-> NA  (M:781808)
Slot=136, dst=1066926, HMID=66 4C 1F 00, cnt=6 (M:930678)
<- 14 06 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:930694)
<- 14 06 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:931393)
<- 14 06 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:932093)
-> NA  (M:932791)
Slot=121, dst=1188904, HMID=66 4C 1F 00, cnt=7 (M:1067156)
<- 14 07 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1067172)
<- 14 07 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1067871)
<- 14 07 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1068571)
-> NA  (M:1069270)
Slot=171, dst=1360624, HMID=66 4C 1F 00, cnt=8 (M:1189126)
<- 14 08 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1189142)
b> 0F 02 86 10 2E A3 AE 00 00 00 0A 88 E3 0D 00 00 (L:16) (M:1189804)

UNKNOWN MESSAGE, PLEASE REPORT!

<- 14 08 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1189841)
<- 14 08 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1190541)
-> NA  (M:1191240)
Slot=157, dst=1517631, HMID=66 4C 1F 00, cnt=9 (M:1360633)
<- 14 09 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1360649)
-> 0A 09 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:1360797)
Slot=142, dst=1660319, HMID=66 4C 1F 00, cnt=10 (M:1517821)
<- 14 0A A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1517836)
-> 0A 0A 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:1517985)


Hat jemand die V0.15 vom Universalsensor direkt mit einem HM-CC-RT-DN im Einsatz (funktionsfähig; garantiert ohne Bursting)?

Viele Grüße,
Martin

[Dirk]

Hallo Martin,

allerdings hatte ich nur sporadische Datenübertragungen.

Das hatte ich ursprünglich auch. (Bis einschliesslich V0.14)
Wichtig ist hier das berechnete Timing. Das darf nicht durch andere Prozesse, Waits usw. verzögert werden. Und wenn, dann muss die Zeit für die nächste "Sendung" korrigiert werden.

Weiterhin habe ich auch festgestellt, daß wohl durch einen Compilerfehler (oder sonstigen Bug / Überschreiber in der Lib)
die Meßdaten nicht normal gesendet, sondern geburstet werden.

Was meinst du damit? Normal sendet der Sensor die Daten wenn er nicht gepeert ist genau einmal an die Broadcast Adresse. Ansonsten wird an die Peer-Adresse gesendet und auch ein ACK gewartet. Wenn das ACK ausbleibt, wird das Senden noch N-Mal wiederholt. N wird im transmDevTryMax-Register definiert.

In diesem Falle funktioniert die Kommunikation mit dem RT-DN dauerhaft.

Vermutlich weil eine der drei Sendungen dann zufällig in den "normalen" Sendeslot passt.

Hat jemand die V0.15 vom Universalsensor direkt mit einem HM-CC-RT-DN im Einsatz (funktionsfähig; garantiert ohne Bursting)?

So hatte ich das jedenfalls erfolgreich getestet.

Du hast nicht zufällig die Unterstützung für den US-Sensor einkommentiert?
Diese Codeteile dürften das Timing für das Peering mit dem HM-CC-RT-DN aktuell "versauen". Siehe auch der Kommentar in der Readme:

Experimental support for US-100 ultrasonic distance sensor (Do not use this experimental feature if you need the peering with HM-CC-RT-DN an this time)

Viele Grüße
Dirk