Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Dirk]

Noch mal was zum Thema Lazy-Config. Also das Übertragen der Registereinstellungen bei der nächsten Übertragung.
Also ohne das explizite Drücken der Config-Taste.

Ich habe das die letzten Tage noch einmal evaluiert. Grundsätzlich funktioniert das. Auch wenn es manchmal etwas dauert. Allerdings habe ich das Ganze aktuell nur zusammen mit der CCU erfolgreich getestet.

Mit FHEM klappt das aus irgendeinem Grund nicht. FHEM "gibt hier einfach zu früh auf" und quittiert den Versuch dann mit einem Fehler.

Hat schon mal jemand das Ganze z.B. mit einem anderen batteriebetriebenen Device getestet, welches nicht im Burst-Mode ist, getestet? Auch bei einem Bewegungsmelder wollte FHEM keine Register ohne Drücken der Config-Taste aktualisieren.

Gruß
Dirk

[frank]

Noch mal was zum Thema Lazy-Config. Also das Übertragen der Registereinstellungen bei der nächsten Übertragung.
Also ohne das explizite Drücken der Config-Taste.

Ich habe das die letzten Tage noch einmal evaluiert. Grundsätzlich funktioniert das. Auch wenn es manchmal etwas dauert. Allerdings habe ich das Ganze aktuell nur zusammen mit der CCU erfolgreich getestet.

hi dirk,

was du hier als lazy-config beschreibst, ist das nicht eigentlich wakeup-config?
also wie bei einem thermostat, das regelmässig wetterdaten sendet.

lazy-config wäre nach meinem verständnis dann eher nach einem event, wie beim fensterkontakt oder eben motion beim bm.

würde diese "automatische" config denn auch in fw 0.14 funktionieren, oder erst mit 0.15?

edit:
wäre es möglich die namen deiner update-files ein klein wenig zu ändern, sodass der name kompatibel zu eq3 wird. dann wäre es einfacher deine files eventuell in meinen update-check einzubauen http://www.fhemwiki.de/wiki/HomeMatic_Firmware_Update#Tool_zur_Firmware_Versionspr.C3.BCfung

bisher:            HB-UW-Sen-THPL_update_V0_14_001_150301-I.tgz
demnächst:     HB-UW-Sen-THPL-I_update_V0_14_001_150301.tgz

also den kompletten model-namen, wie in fhem benutzt, an den anfang des namens setzen und am ende nur das release date.

gruss frank

[vbs]

Also generell funktioniert das bei mir in FHEM mit HM-CFG-USB:
Wenn ich zB Register in einem HM-Bewegungsmelder ändere, dann werden die übertragen, wenn ich das nächste mal daran vorbeilaufe. Auch daran zu sehen, dass er dann recht wild blinkt.
Wie das genau heißt, kann ich allerdings nicht sagen.

[Linef]

Hallo Martin,
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.

Das Timing sollte ok sein. Aktuell lese ich keine Hardware-Sensoren aus, sondern erzeuge nur Dummy-Werte - das HM-Sensor-Modul liefert also immer gleichbleibende Temperatur, Feuchte und Druck. Keine Helligkeit und Batteriespannung. Damit geht der "Auslesevorgang" natürlich sehr schnell.

In SHT10_BMP085_TSL2561::poll_transmit lasse ich mir nach dem Aufruf von sendPeerWEATHER ein paar Debugs raus (Die Zeilen mit dem Slot=...). dst gibt dabei die nächste "Ziel"-Zeit an - also wenn das nächste Paket gesendet werden soll laut calcSendSlot. cnt ist der Message-Counter, der der Berechnung in calcSendSlot zugrunde liegt. Ich habe auch noch eine kleine Änderung in power_poll eingebaut, damit er beim peer_senden nicht noch zusätzlich 250ms "verschwendet". Damit ist das Timing eigentlich fast exakt (s.u.).

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.

Mit Übersetzen Deines Originalcodes wird im 3. Byte der Message statt "A2" (wie es eigentlich durch die Einstellungen auch sein sollte) ein "B2" gesendet und damit ein Burst. Das läßt sich sehr schön durch Einschalten der Debug Message "send burst" im CC110x Modul erkennen:

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: 1
Config changed. Data:  (L:0)
lowBatLimit: 16
ledMode: 1
burstRx: 0
transmDevTryMax: 3
altitude: 0
Slot=515 (128), dst=129786, HMID=66 4C 1F 00, cnt=255 (M:1038)
send burst
<- 14 00 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1437)
-> 0A 00 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:1558)
Slot=635 (158), dst=288537, HMID=66 4C 1F 00, cnt=0 (M:129789)
send burst
<- 14 01 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:130189)
send burst
<- 14 01 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:130887)
-> 0A 01 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:131010)
Slot=577 (144), dst=432788, HMID=66 4C 1F 00, cnt=1 (M:288540)
send burst
<- 14 02 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:288940)
-> 0A 02 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:289060)
Slot=520 (130), dst=562789, HMID=66 4C 1F 00, cnt=2 (M:432791)
send burst
<- 14 03 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:433190)
-> 0A 03 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:433311)
Slot=718 (179), dst=742290, HMID=66 4C 1F 00, cnt=3 (M:562792)
send burst
<- 14 04 B2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:563191)
-> 0A 04 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:563312)


Wenn ich nun z.B. die Debug-Meldungen in send_peer_poll aktiviere (zur Ausgabe von lB[0]), dann wird tatsächlich ein A2 gesendet und damit ist auch der Burst weg. Ich kann auch statt dem Einschalten der Debugs z.B. ein lb[0]=0 hart setzen, dann kommt auch kein Burst. Oder ich definiere lB als static - dann kommt auch keiner...

Das Verhalten habe ich mit der Arduino IDE 1.6.8, hatte ich auch mit 1.6.6 und habe es mit AtmelStudio 7.0.

Ich bin auch schon den erzeugten Assembler-Code durchgegangen - konnte aber keinen Fehler finden.
Vielleicht kannst Du das bei Dir mal verifizieren ob hier nicht doch zufällig geburstet wird...
Mein Code wäre auch hier verfügbar: https://github.com/LineF/Wettersensor.git und https://github.com/LineF/AskSin.git, jeweils develop Branch.

Vermutlich weil eine der drei Sendungen dann zufällig in den "normalen" Sendeslot passt.
So hatte ich das jedenfalls erfolgreich getestet.

Wenn zum Peer geburstet wird, dann funktioniert's immer. Egal wann ich mit der Sequenz starte (z.B. kurz hintereinander den Sensor starten - RT-DN meldet sich immer)

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:

Nein.

Hier die Sendungen ohne Burst:

Code Auswählen Erweitern


Slot=653 (163), dst=1618042, HMID=66 4C 1F 00, cnt=13 (M:1454794)
rB:F6
<- 14 0E A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1454811)
<- 14 0E A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1455509)
<- 14 0E A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1456209)
-> NA  (M:1456908)
Slot=595 (148), dst=1766792, HMID=66 4C 1F 00, cnt=14 (M:1618044)
rB:F6
<- 14 0F A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1618061)
-> 0A 0F 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:1618208)
Slot=538 (134), dst=1901293, HMID=66 4C 1F 00, cnt=15 (M:1766795)
rB:F6
<- 14 10 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1766811)
<- 14 10 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1767510)
<- 14 10 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1768210)
-> NA  (M:1768908)
Slot=480 (120), dst=2021293, HMID=66 4C 1F 00, cnt=16 (M:1901295)
rB:F6
<- 14 11 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1901312)
<- 14 11 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1902010)
<- 14 11 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:1902710)
-> NA  (M:1903409)
Slot=678 (169), dst=2190794, HMID=66 4C 1F 00, cnt=17 (M:2021296)
rB:F6
<- 14 12 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2021312)
<- 14 12 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2022010)
<- 14 12 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2022711)
-> NA  (M:2023409)
Slot=621 (155), dst=2346044, HMID=66 4C 1F 00, cnt=18 (M:2190796)
rB:F6
<- 14 13 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2190813)
<- 14 13 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2191511)
<- 14 13 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2192211)
-> NA  (M:2192910)
Slot=563 (140), dst=2486795, HMID=66 4C 1F 00, cnt=19 (M:2346047)
rB:F6
<- 14 14 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2346063)
<- 14 14 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2346762)
<- 14 14 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2347462)
-> NA  (M:2348161)
Slot=505 (126), dst=2613046, HMID=66 4C 1F 00, cnt=20 (M:2486798)
rB:F6
<- 14 15 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2486814)
-> 0A 15 80 02 2E 63 9D 1F 4C 66 00 (L:11) (M:2486962)
Slot=704 (176), dst=2789047, HMID=66 4C 1F 00, cnt=21 (M:2613049)
rB:F6
<- 14 16 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2613065)
<- 14 16 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2613764)
<- 14 16 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2614464)
-> NA  (M:2615162)
Slot=646 (161), dst=2950548, HMID=66 4C 1F 00, cnt=22 (M:2789050)
rB:F6
<- 14 17 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2789066)
<- 14 17 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2789765)
<- 14 17 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2790465)
-> NA  (M:2791163)
Slot=588 (147), dst=3097549, HMID=66 4C 1F 00, cnt=23 (M:2950551)
rB:F6
<- 14 18 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2950567)
<- 14 18 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2951266)
<- 14 18 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:2951966)
-> NA  (M:2952665)
Slot=530 (132), dst=3230050, HMID=66 4C 1F 00, cnt=24 (M:3097552)
rB:F6
<- 14 19 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3097569)
<- 14 19 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3098267)
<- 14 19 A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3098968)
-> NA  (M:3099666)
Slot=729 (182), dst=3412300, HMID=66 4C 1F 00, cnt=25 (M:3230052)
rB:F6
<- 14 1A A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3230068)
<- 14 1A A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3230767)
<- 14 1A A2 70 1F 4C 66 2E 63 9D 00 E6 26 01 F4 00 00 00 00 00 00 (L:21) (M:3231467)
-> NA  (M:3232165)


Die Sende-Zeit liegt also nur wenige ms hinter der Sende-Soll-Zeit.

Viele Grüße,
Martin

[Dirk]

Hallo,

was du hier als lazy-config beschreibst, ist das nicht eigentlich wakeup-config?
also wie bei einem thermostat, das regelmässig wetterdaten sendet.

lazy-config wäre nach meinem verständnis dann eher nach einem event, wie beim fensterkontakt oder eben motion beim bm.

Gibt es diese Separation beim Wording? Ich kannte bisher nur "Lazy-Config" als Begriff. Aber ok.
Wenn das Device zyklisch sendet, dann heisst es "Lazy-Config", wenn er bei einem Event sendet heisst es "Wakeup-config"?

Ich meine aber, dass es hier technisch keine Unterschiede gibt. Die in der "Zentrale" stehen Config-Nachrichten für das Device an, wenn das Device sendet, dann sendet es ein "Wake me up"-Flag und dann sollte die "Zentrale" beginnen die Config-Daten zu übermitteln.

würde diese "automatische" config denn auch in fw 0.14 funktionieren, oder erst mit 0.15?

Ich habe es mit meinen Wettersensoren (v0.14) und der CCU1 getestet. Damit hatte es auch funktioniert.

wäre es möglich die namen deiner update-files ein klein wenig zu ändern, sodass der name kompatibel zu eq3 wird.
bisher:            HB-UW-Sen-THPL_update_V0_14_001_150301-I.tgz
demnächst:     HB-UW-Sen-THPL-I_update_V0_14_001_150301.tgz

Ja, denke das kann ich machen. Falls ich das vergesse bitte noch mal erinnern
[/quote]

Also generell funktioniert das bei mir in FHEM mit HM-CFG-USB:
Wenn ich zB Register in einem HM-Bewegungsmelder ändere, dann werden die übertragen, wenn ich das nächste mal daran vorbeilaufe. Auch daran zu sehen, dass er dann recht wild blinkt.

Ok, Dann werde ich das nochmal näher untersuchen. Vermutlich fehlt da noch was in der "HMConfig_SenTHPL.pm"

Ich habe auch noch eine kleine Änderung in power_poll eingebaut, damit er beim peer_senden nicht noch zusätzlich 250ms "verschwendet". Damit ist das Timing eigentlich fast exakt (s.u.).

Mit Übersetzen Deines Originalcodes wird im 3. Byte der Message statt "A2" (wie es eigentlich durch die Einstellungen auch sein sollte) ein "B2" gesendet und damit ein Burst.

Ich schaue mir das dann mal an.

Viele Grüße
Dirk

[VolkerNT]

Hallo Dirk,

ich hätte  Interesse an einen Außensensor.

MfG
Volker

[wegi30]

Hallo Dirk,

Ich hätte auch Interesse an einen Außensensor.

Viele Grüße, Michael

[Tom71]

Hallo,
ich hab den Innensensor selbst nachgebaut und stosse nun leider auf ein Problem. Den OTA-Bootloader hab ich erfolgreich geflasht. Wenn ich nun aber die Firmware per OTA flashe, startet der Sensor nicht und reagiert nicht auf den Config-Button:

Code Auswählen Erweitern


sudo flash-ota -c /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03VVGB-if00-port0 -f HB-UW-Sen-THPL_update_V0_14_001_150301.eq3 -s SERIAL

HomeMatic OTA flasher version 0.102-git

Reading firmware from HB-UW-Sen-THPL_update_V0_14_001_150301.eq3...
Firmware with 224 blocks successfully read.
Opening culfw-device at path /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03VVGB-if00-port0 with speed 38400
Requesting firmware version
culfw-device firmware version: a-culfw
Entering 10k-mode
Waiting for device with serial SERIAL
Device with serial SERIAL(HMID: HM_ID) entered firmware-update-mode
Initiating remote switch to 100k
Entering 100k-mode
Has the device switched?
Yes!
Flashing 224 blocks: 0224/0224 -
Entering 10k-mode
Waiting for device to reboot

Die LED flackert auch beim Flashen.
Danach startet allerdings nicht die Sensor Software. Auch wenn ich per RX/TX draufschaue, sehe ich "Asksin OTA Bootloader ... Starte App" und dann nichts mehr.
Hat jemand vielleicht einen Tip, was ich noch versuchen kann? Ich vermute mal, dass wenn ich den Arduino-Bootloader verwende und seriell flashe, bekomme ich die gleichen Probleme.

Gruss Thomas

[Dirk]

Hallo,

@VolkerNT und @wegi30
Ich hab euch eine PM geschickt.

@Thomas
Das Flashen der Firmware sah erst mal gut aus.
Welche Firmware hast du genommen? Selber kompiliert?
Was sagt die LED nach dem Anlegen der Versorgungsspannung?

Viele Grüße
Dirk

[Tom71]

Hallo Dirk, die LED flackert kurz, 8 mal? Und dann in längeren Abständen.
Die Firmware ist die aus

https://github.com/kc-GitHub/Wettersensor/blob/master/Contrib/HB-UW-Sen-THPL_update_V0_14_001_150301.eq3


Ich weiss nicht was da faul ist. Das sind die Ausgaben beim Flashen:

Code Auswählen Erweitern

AskSin OTA Bootloader V0.7.0

Start App
Starti®ö

AskSin OTA Bootloader V0.7.0

TX bootloader sequence
Wait for CB msg
Got CB msg
Switch to 100k mode
Wait for CB msg
Got CB msg
Receive firmware
.......Timeout
CRC OK
Start App
Starting

Auch wenn ich einen Arduino-Bootloader brenne, ATmegaBOOT_168_atmega328_pro_8MHz.hex, kann ich danach nicht mit Tx/Rx irgendein Programm mit avrdude brennen.

Kann ich die Firmware auch über Miso/Mosi/Sck flashen? Wie könnte das gehen?
Ich bin leider etwas ratlos. Ich hab noch gar keine Sensoren drauf, nur den Spannungsregler und den Atmega.

Update:
Hmm. Ich hab auf einer neuen Platine den Sensor noch einmal gebaut und es funktioniert. Dann hab ich wohl einen Hardware Defekt und werde mal einzelne Bauteile austauschen.

Gruss Thomas

[awel]

Hallo Dirk,

ich habe Interesse an einem Aussensensor.

Vielen Dank, Grüße
Achim

[hm-s]

Hallo,

auf der LXCCU Seite ist dieser Thread als Bezugsquelle für die Sensoren angegeben.

Ich habe einige Seiten gelesen aber noch keinen Quelle gefunden

Kann mir jemand weiterhelfen?

Vielen Dank

[Thorsten Pferdekaemper]

auf der LXCCU Seite ist dieser Thread als Bezugsquelle für die Sensoren angegeben.
Ich habe einige Seiten gelesen aber noch keinen Quelle gefunden

Hi,
am besten Du schreibst eine PM an dem Forumsuser "Dirk".
Gruß,
   Thorsten

[rvideobaer]

Hallo,

ich habe bei einem HM configcheck festgestellt das der Sensor dort mehrere Einträge hat.

configCheck done:

missing register list
    HM_Sensor:   RegL_00.

PairedTo missing/unknown
    HM_Sensor

weis jemand ob man das beheben kann.

Gruß Rolf

[Bennemannc]

Hallo,

weis jemand ob man das beheben kann.

Normalerweise sollte ein "GetConfig" auf das Gerät ausreichen (anschließend die Configtaste am Gerät drücken). Anschließend solltest Du die Konfiguration in HMInfo abspeichern - sonst ist diese eventuell nach einen Neustart von Fhem weg. Wenn Du die gespeichert hast, kannst Du die Werte mit "Config restore" wieder einlesen.
"Paired to missin/unknown" bedeutet nicht unbedingt, das das Gerät nicht gepairt ist - es kann auch sein, das nur das Reading nicht - noch nicht - nicht mehr (clear Readings) von HMInfo in Fhem zu finden ist.

Gruß Christoph