@socke85 ich habe den gleichen Fehler. Konntest du schon eine Lösung finden? Danke

@nitrox9 danke für die umfangreiche Erklärung und die Links! Ich habe soweit alles entsprechend umgesetzt, bekomme nun aber im Modbus Adapter nicht dev/ttyUSB0, sondern dev/ttyAMA0 angezeigt. Auch wechselt der Adapter ständig von gelb nach grün, Werte sind noch keine angekommen. Weißt du, oder jemand hier aus der Runde, Rat? Danke vorab, Markus

@killroy2 Nach Update auf 0.2.6 funktioniert's jetzt, vielen Dank!

@killroy2 Hi, stehe etwas auf dem Schlauch. Grün wird mir dort nichts angezeigt. Hier ein Ausschnitt aus dem Gruppenmonitor, in diesem Falle geschaltet aus dem iobroker heraus. Die Status- GA in der ETS bekommt dann den richtigen Wert. Im Objekt im iobroker kommt aber nichts an.

Grüße

@killroy2 Guten Abend, war ein paar Tage off, sorry. Danke für deine schnelle Rückmeldung.

Bei Hovern erhalte ich:
Wert: (null)
Bestätigt: true
Zeitstempel 17.11.
Zuletzt geändert: 06.11.
Von: openknx.0
Benutzer: admin
Qualität: 0x00 good

Folgendes bekomme ich aus dem Log für eine GA (Mähroboter), bei der das Status-Objekt nicht geschrieben wird (erst das Log der Schalten GA 2.1.23, dann kommt die Status-GA 2.2.23:

2022-11-17 12:49:36.857 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.857 2022-11-17 11:49:36 **** (2/1/23) false DATAPOINT CHANGE (was: true)
2022-11-17 12:49:36.857 - debug: openknx.0 (19479) Inbound GroupValue_Write from 1.1.243 GA 2/1/23 to Object: openknx.0.Steckdosen.Ein_Aus.A04_Garten_Außensteckdose_Süd_Mähroboter val: false dpt: DPT1.001
2022-11-17 12:49:36.858 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.858 (idle): UDP sent OK: TUNNELING_ACK 06100421000a0413ae00
2022-11-17 12:49:36.881 - silly: openknx.0 (19479) States user redis pmessage openknx.0.*/openknx.0.Steckdosen.Ein_Aus.A04_Garten_Außensteckdose_Süd_Mähroboter:{"val":false,"ack":true,"ts":1668685776870,"q":0,"from":"system.adapter.openknx.0","user":"system.user.admin","lc":1668685776870}
2022-11-17 12:49:36.969 - silly: openknx.0 (19479) [debug] 2022-11-17 11:49:36.969 Inbound message: 0610042000150413af002900bce011011217010080
2022-11-17 12:49:36.969 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.969 (idle): Received TUNNELING_REQUEST_L_Data.ind message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"tunnstate":{"header_length":4,"channel_id":19,"seqnum":175,"rsvd":0},"cemi":{"msgcode":41,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":0,"confirm":0,"destAddrType":1,"hopCount":6,"extendedFrame":0},"src_addr":"1.1.1","dest_addr":"2/2/23","apdu":{"apdu_length":1,"apdu_raw":{"type":"Buffer","data":[0,128]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[0]}}}}
2022-11-17 12:49:36.970 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.970 (recvTunnReqIndication): Sending TUNNELING_ACK ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":19,"tunnel_endpoint":"192.168.1.74:3671","seqnum":175}}
2022-11-17 12:49:36.970 - silly: openknx.0 (19479) [debug] 2022-11-17 11:49:36.970 (idle): zzzz...
2022-11-17 12:49:36.970 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.970 2022-11-17 11:49:36 **** (2/2/23) false DATAPOINT CHANGE (was: true)
2022-11-17 12:49:36.970 - debug: openknx.0 (19479) receive self ga: 1.1.1
2022-11-17 12:49:36.970 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:36.970 (idle): UDP sent OK: TUNNELING_ACK 06100421000a0413af00
2022-11-17 12:49:40.829 - silly: openknx.0 (19479) [debug] 2022-11-17 11:49:40.829 Inbound message: 0610042000150413b0002900bce011f31118010081
2022-11-17 12:49:40.831 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:40.830 (idle): Received TUNNELING_REQUEST_L_Data.ind message: {"header_length":6,"protocol_version":16,"service_type":1056,"total_length":21,"tunnstate":{"header_length":4,"channel_id":19,"seqnum":176,"rsvd":0},"cemi":{"msgcode":41,"addinfo_length":0,"ctrl":{"frameType":1,"reserved":0,"repeat":1,"broadcast":1,"priority":3,"acknowledge":0,"confirm":0,"destAddrType":1,"hopCount":6,"extendedFrame":0},"src_addr":"1.1.243","dest_addr":"2/1/24","apdu":{"apdu_length":1,"apdu_raw":{"type":"Buffer","data":[0,129]},"tpci":0,"apci":"GroupValue_Write","data":{"type":"Buffer","data":[1]}}}}
2022-11-17 12:49:40.832 - silly: openknx.0 (19479) [trace] 2022-11-17 11:49:40.831 (recvTunnReqIndication): Sending TUNNELING_ACK ==> {"header_length":6,"protocol_version":16,"service_type":1057,"total_length":10,"hpai":{"protocol_type":1,"tunnel_endpoint":"0.0.0.0:0"},"tunnstate":{"channel_id":19,"tunnel_endpoint":"192.168.1.74:3671","seqnum":176}}
2022-11-17 12:49:40.832 - silly: openknx.0 (19479) [debug] 2022-11-17 11:49:40.832 (idle): zzzz...

Hallo,
ich nutze den Adapter (0.2.5) seit einigen Wochen und möchte mich zunächst für die tolle Arbeit bedanken!

Nun stehe ich vor einem Problem, dass bestimmte Objekte nicht gesschrieben werde; in diesem Fall Rückmeldungs-GAs von verschiedenen Steckdosen. Andere wiederum funktionieren.

Hier einmal ein Beispiel, bei dem es funktioniert:

und hier ein Beispiel, bei es nicht funktioniert:

Mir fällt auf, dass die Zeile "from" abweicht. In dem Fall, wo es nicht funtkioniert, ist dort "admin" angegeben, im anderen Fall "openknx". Wenn ich dies auf openknx ändere und abspeichere, wird es wieder mit admin überschrieben.
Im Gruppenmonitor der ETS5 kann ich sehen, dass die Status-GAs geschrieben werden, nur werden einzelne Objekte nicht geschrieben. Die Flags und DPTs in den verschiedenen Status GAs sind alle gleich.

Kann es damit zusammenhängen, dass ich nach einer ersten Installation des Adapaters Aliase erstellt habe? Diese habe ich im Nachgang im Objektbaum direkt gelöscht, sowie auch die Instanz. Nach Neuistallation des Adapters wollte ich hier ohne Aliase starten.

Danke vorab!