HB-UNI-Sensor1-THPD-BME280

[FUEL4EP]

Es ist mir gelungen, das Phänomen in meiner Testumgebung ein wenig weiter einzukreisen. In diesem Ausschnitt der Ausgaben des seriellen Monitors sind zwei Tastendrücke auf den Config-Taster dargestellt, die nach der Eingabe eines Testprogramms mit entsprechender Statusmeldung erfolgten:

Code: Alles auswählen

09:10:51.530 ->  debounce
09:10:51.629 ->  pressed
09:10:51.695 ->  released
09:10:51.762 -> <- 1A 21 80 00 F60401 123456 10 F6 04 42 4D 45 32 38 30 54 48 50 31 70 01 01 01  - 290775
09:10:51.762 -> 
09:10:54.145 ->  debounce
09:10:54.178 ->  pressed
09:10:54.277 ->  released
09:10:54.311 -> <- 1A 22 80 00 F60401 123456 10 F6 04 42 4D 45 32 38 30 54 48 50 31 70 01 01 01  - 293322
09:10:54.311 -> 
09:10:54.410 -> -> 0A 22 81 02 123456 F60401 00  - 293435
09:10:54.443 -> -> 0B 2B A0 01 123456 F60401 01 03  - 293459
09:10:54.575 -> <- 0E 2B 80 10 F60401 123456 01 00 00 00 00  - 293588
09:10:54.675 -> -> 10 34 A0 01 123456 F60401 01 01 19 57 4D 3F 00  - 293707
09:10:54.741 -> * Config Changed         : List1
09:10:54.741 -> * Temperature Offset x10 : 1
09:10:54.741 -> * Humidity Offset x10    : 0
09:10:54.741 -> * Pressure Offset x10    : 0
09:10:54.741 -> BME280 sensor OK
09:10:54.741 -> BME280 offsets (all x10):
09:10:54.741 -> -T    : 1
09:10:54.741 -> -P    : 0
09:10:54.741 -> -H    : 0
09:10:54.807 -> <- 0E 34 80 02 F60401 123456 01 01 00 00 60  - 293828
09:11:01.726 -> ignore 0C 22 86 70 2C79C1 000000 00 F5 1F  - 300730
09:11:03.944 -> ignore 0F FE 86 10 67F020 000000 0A B0 FB 0D 00 00  - 302921
09:11:06.860 -> ignore 0F 0F 86 10 640308 000000 0A B8 F5 0C 45 00  - 305864

Beim ersten Tastendruck wird die Statusmeldung nicht gelöscht. Beim zweiten Tastendruck, ca. 3 Sekunden später, wird die Statusmeldung gelöscht.
Der Unterschied ist, das beim ersten Tastendruck die Quittung der Zentrale (-> 0A 22 81 02 123456 F60401 00) nicht erfolgt / nicht empfangen wird.

Woran kann das liegen?

Wenn Kanalparameter geändert werden, wird die Statusmeldung durch Drücken der Config-Taste zuverlässig und sofort zurückgenommen.
Das Phänomen tritt also nur bei dem Anlegen oder Löschen eines Zentralenprogramms auf.

EDIT: Im LOG der Raspberrymatic konnte ich das Phänomen nun auch fassen:

Code: Alles auswählen

Mar  4 09:57:24 homematic-raspi user.debug rfd: Event: BME280THP1:0.CONFIG_PENDING=true
Mar  4 09:57:24 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
Mar  4 09:57:24 homematic-raspi user.debug rfd: Saving device BME280THP1
Mar  4 09:57:24 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Mar  4 09:57:24 homematic-raspi local0.err ReGaHss: ERROR: rpc.CallReportValueUsage failed dp id = 38887 [DeleteObject():iseManageObj.cpp:120]
Mar  4 09:57:24 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Mar  4 09:57:24 homematic-raspi user.debug rfd: Saving device BidCoS-RF

Mar  4 09:57:50 homematic-raspi user.debug rfd: RX for BME280THP1: @1411796151 RSSI=-52dB 0xF60401 -> 0x123456 SYSINFO [OEQ1234567]:   CNT=62,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x00   SYSINFO_SWVER = 0x10   SYSINFO_TYPE = 0xF604   SYSINFO_SERIAL = BME280THP1   SYSINFO_CODE = 0x7001   SYSINFO_CH_A = 1   SYSINFO_CH_B = 1
Mar  4 09:57:50 homematic-raspi user.debug rfd: Device has been woken up
Mar  4 09:57:50 homematic-raspi user.debug rfd: TX:  @1411796152 0x123456 -> 0xF60401 CONFIG_PEER_LIST_REQ [OEQ1234567]:   CNT=71,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01   CONFIG_CHANNEL = 1
Mar  4 09:57:50 homematic-raspi user.debug rfd: (OEQ1234567) Response status: Telegram sent, received ACK.
Mar  4 09:57:50 homematic-raspi user.debug rfd: Response accepted:  @1411796421 RSSI=-167dB 0xF60401 -> 0x123456 INFO_PEER_LIST [OEQ1234567]:   CNT=71,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x10   LINK_PEER_ADDRESS = 0x123456   LINK_PEER_CHANNEL = 63   LINK_PEER_ADDRESS = 0x000000   LINK_PEER_CHANNEL = 0   LINK_PEER_ADDRESS = 0x000000   LINK_PEER_CHANNEL = 0   LINK_PEER_ADDRESS = 0x000000   LINK_PEER_CHANNEL = 0
Mar  4 09:57:50 homematic-raspi user.debug rfd: RFChannel::GetLinkPeersFromDevice, Link von 16122881 mit Addresse 1660749
Mar  4 09:57:50 homematic-raspi user.debug rfd: TX:  @1411796422 0x123456 -> 0xF60401 CONFIG_PEER_REMOVE [OEQ1234567]:   CNT=80,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01   CONFIG_CHANNEL = 1   CONFIG_PEER_ADDRESS = 0x123456   CONFIG_PEER_CHANNEL = 63
Mar  4 09:57:51 homematic-raspi user.debug rfd: (OEQ1234567) Response status: Telegram sent, received ACK.
Mar  4 09:57:51 homematic-raspi user.debug rfd: Response accepted:  @1411796658 RSSI=-167dB 0xF60401 -> 0x123456 ACK_STATUS [OEQ1234567]:   CNT=80,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x02   CHANNEL = 1   STATUS = 0   STATE = 0   CLOCK = 0   LOWBAT = 0   DUTY_CYCLE = 0   RSSI = 96
Mar  4 09:57:51 homematic-raspi user.debug rfd: (OEQ1234567) Response status: OK, Data.
Mar  4 09:57:51 homematic-raspi user.debug rfd: Event: BME280THP1:0.CONFIG_PENDING=false
Mar  4 09:57:51 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
Mar  4 09:57:51 homematic-raspi user.debug rfd: (OEQ1234567) Response status: OK, Data.
Mar  4 09:57:51 homematic-raspi user.debug rfd: Sysinfo received by OEQ1234567 while not in install mode:BME280THP1 (HB-UNI-Sensor-THPD-BME280)
Mar  4 09:57:51 homematic-raspi user.debug rfd: RX for BME280THP1: @1411796658 RSSI=-167dB 0xF60401 -> 0x123456 ACK_STATUS [OEQ1234567]:   CNT=80,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x02   CHANNEL = 1   STATUS = 0   STATE = 0   CLOCK = 0   LOWBAT = 0   DUTY_CYCLE = 0   RSSI = 96
Mar  4 09:57:51 homematic-raspi user.debug rfd: Saving device BME280THP1

Es ist wieder die RF-Kommunikation für zwei Config-Tastendrücke aufgezeichnet. Der erste Tastendruck um 09:57:24 war erfolglos und liefert einen ReGaHss: ERROR: rpc.CallReportValueUsage failed dp id.

Der zweite Tastendruck war erfolgreich.

Der Verdacht besteht, dass der ReGaHss: ERROR: rpc.CallReportValueUsage failed dp id die Ursache sein könnte. Hier brauche ich definitiv Hilde der Experten.

[FUEL4EP]

Hier nochmal ein RM LOG bei einer nicht funktionierenden Statusrücknahme:

Code: Alles auswählen

Mar  4 10:27:16 homematic-raspi user.debug rfd: RX for BME280THP1: @1413562310 RSSI=-68dB 0xF60401 -> 0x123456 SYSINFO [OEQ123456]:   CNT=7,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x00   SYSINFO_SWVER = 0x10   SYSINFO_TYPE = 0xF604   SYSINFO_SERIAL = BME280THP1   SYSINFO_CODE = 0x7001   SYSINFO_CH_A = 1   SYSINFO_CH_B = 1
Mar  4 10:27:16 homematic-raspi user.debug rfd: Device has been woken up
Mar  4 10:27:16 homematic-raspi user.debug rfd: TX:  @1413562310 0x123456 -> 0xF60401 CONFIG_PEER_LIST_REQ [OEQ123456]:   CNT=16,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01   CONFIG_CHANNEL = 1
Mar  4 10:27:17 homematic-raspi user.debug rfd: (OEQ123456) Response status: Telegram sent, received ACK.
Mar  4 10:27:17 homematic-raspi user.debug rfd: Response accepted:  @1413563126 RSSI=-165dB 0xF60401 -> 0x123456 INFO_PEER_LIST [OEQ123456]:   CNT=16,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x10   LINK_PEER_ADDRESS = 0x000000   LINK_PEER_CHANNEL = 0   LINK_PEER_ADDRESS = 0x000000   LINK_PEER_CHANNEL = 0   LINK_PEER_ADDRESS = 0x000000   LINK_PEER_CHANNEL = 0   LINK_PEER_ADDRESS = 0x000000   LINK_PEER_CHANNEL = 0
Mar  4 10:27:17 homematic-raspi user.debug rfd: TX:  @1413563127 0x123456 -> 0xF60401 CONFIG_PEER_ADD [OEQ123456]:   CNT=25,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01   CONFIG_CHANNEL = 1   CONFIG_PEER_ADDRESS = 0x123456   CONFIG_PEER_CHANNEL_A = 63   CONFIG_PEER_CHANNEL_B = 0
Mar  4 10:27:18 homematic-raspi user.debug rfd: (OEQ123456) Response status: Send failed.
Mar  4 10:27:18 homematic-raspi user.debug rfd: SendFrame failed 1 times:  @1413563127 0x123456 -> 0xF60401 CONFIG_PEER_ADD [OEQ123456]:   CNT=25,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01   CONFIG_CHANNEL = 1   CONFIG_PEER_ADDRESS = 0x123456   CONFIG_PEER_CHANNEL_A = 63   CONFIG_PEER_CHANNEL_B = 0
Mar  4 10:27:18 homematic-raspi user.debug rfd: (OEQ123456) Response status: OK, Data.
Mar  4 10:27:18 homematic-raspi user.debug rfd: TX:  @1413564331 0x123456 -> 0xF60401 CONFIG_PEER_LIST_REQ [OEQ123456]:   CNT=26,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01   CONFIG_CHANNEL = 1
Mar  4 10:27:19 homematic-raspi user.debug rfd: (OEQ123456) Response status: Send failed.
Mar  4 10:27:19 homematic-raspi user.debug rfd: SendFrame failed 1 times:  @1413564332 0x123456 -> 0xF60401 CONFIG_PEER_LIST_REQ [OEQ123456]:   CNT=26,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01   CONFIG_CHANNEL = 1
Mar  4 10:27:19 homematic-raspi user.debug rfd: (OEQ123456) Response status: OK, Data.
Mar  4 10:27:19 homematic-raspi user.debug rfd: Sysinfo received by OEQ123456 while not in install mode:BME280THP1 (HB-UNI-Sensor-THPD-BME280)
Mar  4 10:27:19 homematic-raspi user.debug rfd: Saving device BME280THP1
Mar  4 10:27:28 homematic-raspi user.debug rfd: RX for LEQ0867343: @1413573991 RSSI=-91dB 0x2C79C1 -> 0x000000 WEATHER [OEQ123456]:   CNT=64,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=1,BCAST=1,TYPE=0x70   LOWBAT = 0   TEMP = 250   HUMIDITY = 32   RAINING = 0   RAINCNT = 0   WINDSPEED = 0   WINDDIR = 0   WINDDIR_RANGE = 0   BRIGHTNESS = 0

Hier fällt auf, dass der zu verknüpfende Aktor meldet:

(OEQ123456) Response status: Send failed.

Ich bin da mit meinem "Latein" am Ende

[jp112sdl]

Nimm mal unten im Sketch das hal.activity.savePower<SAVEPWR_MODE>(hal); raus, damit das Gerät dauerhaft wach bleibt und teste den ganzen Spaß nochmal.

[FUEL4EP]

Danke für Deinen Vorschlag:

Nimm mal unten im Sketch das hal.activity.savePower<SAVEPWR_MODE>(hal); raus, damit das Gerät dauerhaft wach bleibt und teste den ganzen Spaß nochmal.

Gemacht. Danach neu geflasht. Sensor von Zentrale abgelernt. Sensor erneut nach Werksreset (Tx power = max) an Zentrale angelernt. Neues Zentralenprogramm angelegt. Ergebnis:

Statutusmeldung geht nicht zuverlässig durch Drücken des Config-Knopfs weg. Es gelang erst nach mehreren Tastendrücken. Gefühlt ist das Verhalten unverändert.

[jp112sdl]

Dann liegt es schon mal nicht daran, dass das Gerät zu früh schlafen geht.
Bleibt evtl noch ein Timing-Problem beim Telegramm/Response

[FUEL4EP]

Ich bin noch an was anderem dran: Es könnte durch die reduzierte TX Transmit Power (+0dBm) kommen.

Als ich nach dem Zurückprogrammieren des Tiefschlafs nochmals Versuche mit Tx Transmit Power (+10dBm) gemacht habe, lief alles OK.

Schon das Einstellen einer TX Transmit Power (+0dBm) ging nicht sofort (Statusmeldung blieb erhalten).

Werde da weiter forschen ..

[FUEL4EP]

Entwarnung: Der Tx Sendepegel war es nur indirekt: Durch das Hantieren und Ziehen an dem Antennendraht ist der wohl abgerissen Nach dem erneuten Anlöten geht auch mit 0dBm Sendeleistung das Zurücksetzen der Statusmeldungen durch das Drücken des Config-Knopfs zuverlässig.

Quintessenz dieses 'zufälligen' Antennenabrisses:

Ein nicht korrekt angelöteter Antennendraht kann das beobachtete Phänomen auslösen.
Nie am Antennendraht ziehen!


@PG201245: Bitte Folgendes prüfen:

1. Ist der Antennendraht korrekt an das CC1101 Modul angelötet? Hat er die richtige Länge?

2. Bitte den HB-UNI-Sensor1-THPD-BME280 Sensor aus der Zentrale ablernen und vollständig löschen.

3. Bitte für den HB-UNI-Sensor1-THPD-BME280 Sensor einen Werksrest durchführen (Config-Taste > 6 Sekunden gedrückt halten).
Das setzt die Tx Sendeleistung auf das Maximum.
Den Sensor in die Nähe der Zentrale stellen. Danach den Sensor erneut anlernen.

4. Nun die Tests mit dem reduzierten Zentralenprogramm machen.

[Hackertomm]

Ich bin noch an was anderem dran: Es könnte durch die reduzierte TX Transmit Power (+0dBm) kommen.

Als ich nach dem Zurückprogrammieren des Tiefschlafs nochmals Versuche mit Tx Transmit Power (+10dBm) gemacht habe, lief alles OK.

Schon das Einstellen einer TX Transmit Power (+0dBm) ging nicht sofort (Statusmeldung blieb erhalten).

Werde da weiter forschen ..

Dass könnte sein, denn ich habe da ebenfalls was anderes eingestellt.
Bei mir steht das auf "sehr gering (-15dbm)".
Bei erscheint der Sensor in Einstellungen-Geräte mit aktuell Grün -56dbm.
Aber er war vor Kurzem auch mit Gelb -92dbm zu sehen.
Ich habe sehr gering gewählt, weil der Abstand zur Zentrale nur 2-3m ist, da dachte ich die Sendeleistung zu reduzieren, wäre nicht schlecht.

[PG201245]

hier das Ergebnis

[FUEL4EP]

Dein Sensor ist nicht angelernt. Das ist an der 000000 Zieladresse zu erkennen.