Weil es dort weder die Verknüpfungsrolle "Empfänger"
Code: Alles auswählen
<link_roles>
<source name="..." />
</link_roles>
Code: Alles auswählen
<link_roles>
<target name="..." />
</link_roles>
Moderator: Co-Administratoren
Weil es dort weder die Verknüpfungsrolle "Empfänger"
Code: Alles auswählen
<link_roles>
<source name="..." />
</link_roles>
Code: Alles auswählen
<link_roles>
<target name="..." />
</link_roles>
Es bedeutet, dass die Kanalanzahl beim Anlernen mitgegeben wird.
0.3 heißt, dass für den Wert 3 Bit zur Verfügung stehen.
Code: Alles auswählen
<channel autoregister="true" index="1" type="HB_GENERIC_RADIATION">
<paramset type="MASTER" id="HB-UNI-Sensor-RAD-AL53_master">
<parameter id="HB_ALARM_LEVEL_COUNTS_PER_MEASUREMENT_INTERVAL">
<logical type="integer" min="1" max="65535" default="65535" unit="cpi"/>
<physical type="integer" interface="config" list="1" index="1" size="2"/>
</parameter>
<parameter id="HB_ALARM_LEVEL_MOVING_AVERAGE">
<logical type="float" min="0.01" max="655.35" default="655.35" unit="cpi"/>
<physical type="integer" signed="true" interface="config" list="1" index="3" size="4"/>
<conversion type="float_integer_scale" factor="100.0"/>
</parameter>
</paramset>
Code: Alles auswählen
17:27:03.641 -> <- 0A 16 80 02 F60801 123456 00 - 45458
17:27:03.674 -> -> 0B 1F A0 01 123456 F60801 01 06 - 45486
Code: Alles auswählen
void configChanged() {
DPRINTLN(F("Config Changed: List1"));
DPRINT(F("alarm level counts per measurement interval : ")); DDECLN(this->getList1().alarm_level_counts_per_measurement_interval());
DPRINT(F("alarm level moving average : ")); DDECLN( (double)(this->getList1().alarm_level_moving_average()) / 100.0 );
al53.init((uint16_t)this->getList1().alarm_level_counts_per_measurement_interval(), (int32_t)this->getList1().alarm_level_moving_average()); // set threshold levels for alarm signals as channel parameters
}
Da steht aber kein count="1" ?
Ich glaube jedoch nicht, dass das was mit deinem Problem zu tun hat.
Code: Alles auswählen
Oct 30 20:11:30 homematic-raspi user.debug rfd: Response accepted: @3529917923 RSSI=-82dB 0xF60801 -> 0x123456 ACK [OEQ1234568]: CNT=40,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=1,BCAST=0,TYPE=0x02
Oct 30 20:11:30 homematic-raspi user.debug rfd: (OEQ1234568) Response status: Send failed.
Oct 30 20:11:30 homematic-raspi user.debug rfd: SendFrame failed 1 times: @3529916838 0x123456 -> 0xF60801 CONFIG_START [OEQ1234568]: CNT=41,RPTEN=1,RPTED=0,BIDI=1,BURST=0,WAKEUP=0,WAKEMEUP=0,BCAST=0,TYPE=0x01 CONFIG_CHANNEL = 1 CONFIG_PEER_ADDRESS = 0x000000 CONFIG_PEER_CHANNEL = 0 CONFIG_PARAM_LIST = 1
Oct 30 20:11:30 homematic-raspi user.debug rfd: (OEQ1234568) Response status: OK, Data.
Oct 30 20:11:30 homematic-raspi user.debug rfd: Sysinfo received by OEQ1234568 while not in install mode:AL53RAD001 (HB-UNI-Sensor-RAD-AL53)
Ja klar. Der Sensor läuft schon seit vielen Wochen im Probebetrieb und sendet artig alle 10 Minuten. Auch die Tx Sendeleistung als Geräteparameter kann ich problemlos einstellen. Mein Problem existiert auch bei maximaler Tx Sendeleistung.
Ja, 20 MHz Quarzfrequenz auf einem ATMega1284P, da viel gerechnet werden muss
Das ist unwahrscheinlich und wäre dann nicht immer so. Der ATMega1284P schläft ja während der gesamten Messung für 10 Minuten, ausser wenn die Zentrale ihn weckt, z.B. für eine Änderung von Parametern. Währenddessen zählt nur der ABLIC S35770 I2C-Zähler mit wenigen uA Verbrauch. Gerechnet wird nur in den Messpausen, die nur ca. 0.3 Sekunden lang sind. Daher ist es unwahrscheinlich, dass ein Parameteränderung gerade in die Messpause fällt.jp112sdl hat geschrieben: ↑30.10.2021, 20:30Evtl. kommt es zu Mehrfach-Versuchen bei der Übertragung, weil das ACK Telegram vom Gerät zur CCU nicht im Zeitrahmen ankommt?
Läuft in deinem Sketch irgendeine blockierende Routine, die zu Problemen bei der zeitgerechten Abarbeitung der Telegramme sorgt?
Die CCU erwartet die Quittung glaub ich innerhalb 125ms.