Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

Begonnen von trilu, 23 Februar 2014, 12:23:22

Vorheriges Thema - Nächstes Thema

papa

Die RTC hat nur einen Sekundentakt. Deshalb müssen die restlichen Millisekunden mit der sysclock gewartet werden.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Gernott

#2971
Es läuft nicht stabil. Es war mit clock.add (..) kompiliert, allerdings ohne den Teil mit den millis aus Tom's hinweis. Werde das mal reinbasteln und nochmal testen.
Die Zeitangaben im Log sind immer Vielfache von 250 ms. Ist das so richtig?
Screenshot_2019-08-04 Home, Sweet Home.png

Tom Major

Hast du RTC option aktiv und 32kHZ Quarz verbaut?
Sonst könnte ev. die Ungenauigkeit des RC-Osc. schon für die Instabilitäten verantwortlich sein wenn das magic Homematic Zeitfenster nicht getroffen wird (Vermutung).
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Gernott

Zitat von: Tom Major am 04 August 2019, 11:50:18
Hast du RTC option aktiv und 32kHZ Quarz verbaut?

Ja, habe ich: Auf dem Board (Aussensensor v2.01) ist ein Quarz 32.768kHz an XTAL angelötet.

Mit der zusätzlichen Schleife aus papa's Sketch ist der Sensor erstmal Amok gelaufen und hat im Sekundentakt gesendet. Ursache war offenbar in Zeile 338 vom Unisensor-Setch clock.add(*this) anstelle von CLOCK.add(*this). Oder hat das eine spezielle Bewandtnis? Zumindest läuft er nun nicht mehr Amok.

Gruß
G.

Gernott

Hallo Tom

Funktioniert die sysclock überhaupt im CLOCK_RTC-Modus?

#ifdef CLOCK_SYSCLOCK
#define CLOCK sysclock
#define SAVEPWR_MODE Sleep<>
#elif defined CLOCK_RTC
#define CLOCK rtc
#define SAVEPWR_MODE SleepRTC
#undef seconds2ticks
#define seconds2ticks(tm) (tm)
#else
#error INVALID CLOCK OPTION
#endif



Tom Major

Also getestet sind damals beide Varianten von mir, Sysclock define und RTC define, das passte.
clock.add in Kleinschreibung, das ist der Parameter der in der trigger Funktion reinkommt und passte bei meinem Tests, wenn du CLOCK.add nimmst wird direkt das define genommen. Kann nur vermuten dass das Senden jede Sekunde mit der neuen Funktion fürs magic Zeitfenster zusammenhängt, keine Ahnung.
Könnte ich mir bei Gelegenheit ev. selbst mal anschauen.

Für RTC option muss auch immer der interne RC-Osc im AVR aktiviert sein, das ist dann seine run clock außerhalb der (RTC-) Sleep Zeiten.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Gernott

#2976
Hallo Tom

Danke für die Antwort. Habe gerade mal papa's Beispielsketch HM-WDS10-TH-O auf die Platine geflasht. Damit läuft es stabil, wie es aussieht. Die Message an den HM-CC-RT-DN wird meistens mit ACK: 01 quittiert, und wenn nicht, wird die Nachricht immer 6x übertragen. Das war z.B. bei meinen Versuchen, den Unisensor umzustricken, nicht der Fall. Dort wird allerdings ebenfalls SleepRTC verwendet, wie ich gesehen habe.

Leider sind meine Kenntnisse und Fähigkeiten begrenzt, bin aber schon an der Spannungsübertragung und der Batteriemessung unter Last interessiert. Ich werde also nochmal etwas vor mich hin dilettieren...

Update
Irgendwas scheint mit der peer-Kommunikation nicht zu stimmen.  Die Peer-message wird nur einmal mit waitAck gesendet, danach nur jeweils 1x, ohne waitACK:
altitude: 0
<- 17 01 84 70 A5A503 28BDCE 01 19 2A 80 2B 00 86 47 00 00 0C 38 00 00  - 231
180.500
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00  - 350
-> 0B 03 A0 01 1EA24B A5A503 01 0E  - 505
-> 0B 03 A0 01 1EA24B A5A503 01 0E  - 702
-> 0B 03 A0 01 1EA24B A5A503 01 0E  - 907
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00  - 1009
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00  - 1656
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00  - 2304
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00  - 2951
waitAck: 00
<- 17 02 A2 70 A5A503 28BDCE 01 11 2A 80 2D 00 86 47 00 00 0C 38 00 00  - 3598
waitAck: 00
166.250
<- 17 03 84 70 A5A503 28BDCE 01 0F 2A 80 2D 00 86 47 00 00 0C 38 00 00  - 4313
151.750
<- 17 04 84 70 A5A503 28BDCE 01 10 2A 80 2E 00 86 47 00 00 0C 38 00 00  - 4429
137.250
<- 17 05 84 70 A5A503 28BDCE 01 0F 2A 80 2E 00 86 47 00 00 0C 38 00 00  - 4542
122.750


Beim Sketch von papa wird jede Message solange gesendet, bis  waitAck: 01 gemeldet wird oder 6 Versuche erreicht sind. Woran das liegen könnte, weiß ich nicht.

Gruß
G.

Tom Major

Zitat von: Gernott am 04 August 2019, 18:14:22
Hallo Tom

Danke für die Antwort. Habe gerade mal papa's Beispielsketch HM-WDS10-TH-O auf die Platine geflasht. Damit läuft es stabil, wie es aussieht. Die Message an den HM-CC-RT-DN wird meistens mit ACK: 01 quittiert, und wenn nicht, wird die Nachricht immer 6x übertragen. Das war z.B. bei meinen Versuchen, den Unisensor umzustricken, nicht der Fall. Dort wird allerdings ebenfalls SleepRTC verwendet, wie ich gesehen habe.

Leider sind meine Kenntnisse und Fähigkeiten begrenzt, bin aber schon an der Spannungsübertragung und der Batteriemessung unter Last interessiert. Ich werde also nochmal etwas vor mich hin dilettieren...

Update
Irgendwas scheint mit der peer-Kommunikation nicht zu stimmen.  Die Peer-message wird nur einmal mit waitAck gesendet, danach nur jeweils 1x, ohne waitACK:

Beim Sketch von papa wird jede Message solange gesendet, bis  waitAck: 01 gemeldet wird oder 6 Versuche erreicht sind. Woran das liegen könnte, weiß ich nicht.

Gruß
G.

Hast du gesehen dass beim Unisensor etwas Kreativität  ;) in dieser Form drin ist:
https://github.com/TomMajor/SmartHome/blob/master/HB-UNI-Sensor1/HB-UNI-Sensor1.ino#L198
Zitat
// als Standard wird BCAST gesendet um Energie zu sparen, siehe Beschreibung unten.
// Bei jeder 20. Nachricht senden wir stattdessen BIDI|WKMEUP, um eventuell anstehende Konfigurationsänderungen auch
// ohne Betätigung des Anlerntaster übernehmen zu können (mit Verzögerung, worst-case 20x Sendeintervall).

papa verwendet im HM-WDS10-TH-O stets BIDI.

Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Gernott

Zitat von: Tom Major am 04 August 2019, 23:15:27
Hast du gesehen dass beim Unisensor etwas Kreativität  ;) in dieser Form drin ist:
Aha, nein habe ich nicht.
Kann es sein, daß für die stabile Synchronisierung die peer-Messages mehrfach gesendet werden müssen, damit sie nicht zu oft in's Leere laufen  und damit immer wieder mal auf den internen Sensor zurückgeschaltet wird? Zumindest ist das meine Beobachtung hier.
Ich werde dann wohl doch den anderen Sketch nehmen. Dort ist der Strom in der Sendepause auch nur 2..3 µA. Kann man da die Spannungsmessung unter Belastung einbauen, oder ist das auch aufwendig?

Tom Major

Zu den peer Messages kann ich nichts sagen, habe ich mich nicht mit beschäftigt.
Wenn die HW stimmt braucht der Unisensor im RTC Betrieb 1uA + die Ruheströme der verbauten Sensoren.
papa hat glaub ich letztens auch die Spannungsmessung unter Belastung eingebaut, schau mal in die Battery Klasse.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Gernott

Ich werde die Tage mal testen, wie stabil es läuft, wenn ich schrittweise die Anzahl der BCAST-Messages reduziere.
Mit dem default-Wert von 20 sieht es so aus.

Tom Major

du könntest ja mal testweise radikal alle messages BIDI machen wie papa in seinem sketch um zu sehen ob damit dein Problem mit dem Peer vollständig gelöst wird..
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Gernott

Zitat von: Tom Major am 05 August 2019, 22:37:19
du könntest ja mal testweise radikal alle messages BIDI machen wie papa in seinem sketch um zu sehen ob damit dein Problem mit dem Peer vollständig gelöst wird..
Nein leider nicht, es gibt immer wieder Aussetzer. Der Sketch von papa (Diagramm oben) und der entsprechend modifizierte Unisensor1-Sketch (unten) verhalten sich praktisch gleich, soweit man das nach einem Tag sagen kann.


Tom Major

Gibt es eigentlich Fehlfunktionen beim Thermostat wenn die Aussetzer kommen oder wird dann der letzte Wert genommen?
Eventuell ist ein Original Thermostat-fähiger Sensor auch nicht anders?
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Gernott

Zitat von: Tom Major am 07 August 2019, 22:49:46
Gibt es eigentlich Fehlfunktionen beim Thermostat wenn die Aussetzer kommen oder wird dann der letzte Wert genommen?
Eventuell ist ein Original Thermostat-fähiger Sensor auch nicht anders?
Der Thermostat springt dann vorübergehend auf die Temperatur seines internen Sensors und regelt dann je nach Differenz heftig herum. Im Versuch habe ich die interne Temperatur um 3.5K nach unten gesetzt, damit man diese  Ereignisse besser sieht. Im Winter ist der Regler meist deutlich wärmer, da er dicht an der Heizung sitzt. Einen originalen Sensor habe ich nicht. Dirk hatte damals bei seinem Sensor, von denen ich hier einige laufen habe, mit der Asksin-FW 0.15 eine stabile Synchronisation erreicht. Ich habe aber keine Ahnung, was er da gegenüber der 0.14 geändert hat. - Falls es nicht besser geht, werde ich einen von diesen Sensoren in den Raum mit dem Regler umziehen.