Geräte-/ Kanalparameter einstellen / firmware rftypes XML Datei

[jp112sdl]

Warum ist es beim HM-ES-TX-WM weder 'Sender' noch 'Empfänger', sondern 'nicht verknüpfbar' ausgewiesen?

Weil es dort weder die Verknüpfungsrolle "Empfänger"

Code: Alles auswählen

      <link_roles>
        <source name="..." />
      </link_roles>

noch "Sender"

Code: Alles auswählen

      <link_roles>
        <target name="..." />
      </link_roles>

gibt.

[FUEL4EP]

Vielen Dank Jérôme!

Dann verhält sich mein neues Gerät ja richtig, was den 'Interface/Konfiguration' Status angeht

[FUEL4EP]

Was bedeutet in einer rftypes XML count_from_sysinfo="23.0:0.3", z.B. hier:

https://github.com/jp112sdl/JP-HB-Devic ... ss.xml#L57

Wie schlüsselt sich "23.0:0.3" auf?

Wann muss dieser Zusatz verwendet werden?

Vielen Dank im Voraus!

[jp112sdl]

Was bedeutet in einer rftypes XML count_from_sysinfo

Es bedeutet, dass die Kanalanzahl beim Anlernen mitgegeben wird.
Im Kanal (<channel index=...) steht also kein fester Count für die Anzahl an Kanälen.

Wie schlüsselt sich "23.0:0.3" auf?

0.3 heißt, dass für den Wert 3 Bit zur Verfügung stehen.
Also max. 7 Kanäle gehen würden.

[FUEL4EP]

Danke, Jérôme.

Ich debugge gerade ein Fehlverhalten meines neuen Sensors. Anzahl der Kanäle ist fix = 1.

Der Ausschnitt aus der XML ist (count_from_sysinfo hatte ich schon entfernt):

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>

Ich habe nun folgendes fehlerhaftes Verhalten:

Die Kanalparameter HB_ALARM_LEVEL_COUNTS_PER_MEASUREMENT_INTERVAL und HB_ALARM_LEVEL_MOVING_AVERAGE werden bei einer Änderung im WebUI korrekt auf den Sensor übertragen und können dort im seriellen Monitor kontrolliert werden.

Nur wird der Empfang der neuen Kanalparameter nicht an die Zentrale bestätigt. Das PopUp Fenster geht nicht weg. Im seriellen Monitor steht nach einer List1 Parameteränderung (id der Zentrale ist anonymisiert):

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

Auffällig ist auch, dass meine configChanged Methode von 'class MeasureChannel' zweimal nach einer Änderung eines Parameters der List1 Parameter durchlaufen wird. Das kenne ich so nicht. Was triggert denn die configChanged Methode?

Hier die init Methode

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
    }

[jp112sdl]

Anzahl der Kanäle ist fix = 1.

Da steht aber kein count="1" ?

<channel autoregister="true" index="1" type="HB_GENERIC_RADIATION">

Ich glaube jedoch nicht, dass das was mit deinem Problem zu tun hat.
Ad hoc fällt mir auch grad nichts ein

[FUEL4EP]

Danke.
Im LOG File der RM sehe ich dazu:

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)

Habe ich mich da wo verzählt: CNT=40 versus CNT=41? Ist CONFIG_CHANNEL = 1 bei einem Kanal richtig (habe die XML inzwischen um count="1" ergänzt, wie erwartet kein Unterschied im Verhalten)?

[jp112sdl]

FreqTest hast du sicherlich gemacht, die Fehlerquelle kann ich bei dir sicherlich ausschließen
Mit dem (AVR-)Takt stimmt aber alles?
Evtl. 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?

[FUEL4EP]

FreqTest hast du sicherlich gemacht, die Fehlerquelle kann ich bei dir sicherlich ausschließen

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.

Mit dem (AVR-)Takt stimmt aber alles?

Ja, 20 MHz Quarzfrequenz auf einem ATMega1284P, da viel gerechnet werden muss

Evtl. 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?

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]

Und was macht dein al53.init(...); ? Passiert da irgendwas, was länger dauert?

die nur ca. 0.3 Sekunden lang sind

Die CCU erwartet die Quittung glaub ich innerhalb 125ms.