Wunderschönen guten Morgen,
hab grad ein kleines Problemchen bei mir festgestellt, vielleicht kann mir ja einer helfen und sagen was ich falsch mache .
Hab bei TW einen Neustart ausgeführt und danach bei Edomi.
Beim Neustarten von edomi, werden am Anfang immer alle gewünschten Gruppenadressen abgefragt (Read Request), damit der Status bekannt sind.
Dabei ist mir aufgefallen, dass bei den IButtons, IO's mit Feuchtesensoren und bei 2 Logikausgängen vom TW dies fehlgeschlagen ist (mehr wird vom TW nicht abgefragt).
In der ETS hab ich das L-Flag sowie alle anderen aktiviert, bzw. waren diese ja vom Anfang an so (abgesehen von "lesen bei Init"):
Wenn ich in den Gerätemanager von I-Wire gehe, sehe ich den aktuellen Status des IButtons:
Und im Logikmanager wird auch der aktuell richtige Live-Status angezeigt:
Mir ist aufgefallen, dass nachdem ich den IButton einmal entfernt und wieder dran gemacht habe, konnte ich erfolgreich ein Read Request durchführen.
Davor hat dies nicht geklappt. Hat das was mit den Flags in der ETS zu tun, oder liegt der Fehler wo anderst?
NEU! UPGRADE IP 10 verfügbar!
Optimierte Darstellung von VISU Editor und VISU Client - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/8HzePCm3
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur IP 10
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
Optimierte Darstellung von VISU Editor und VISU Client - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/8HzePCm3
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur IP 10
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
[V2.0 Insider Preview 3.1] Read Request funktioniert nicht (sofort)
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
- Reactions:
- Beiträge: 159
- Registriert: Di Okt 23, 2018 9:27 pm
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 37 Mal
[V2.0 Insider Preview 3.1] Read Request funktioniert nicht (sofort)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Gruß Ben
TWS 960Q ID:359, VPN offen, Reboot erlaubt
TWS 960Q ID:359, VPN offen, Reboot erlaubt
-
- Reactions:
- Beiträge: 3744
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1168 Mal
- Danksagung erhalten: 2076 Mal
Hallo Ben!
Das Verhalten ist wie folgt:
Der KNX-Stack antwortet auf Lese-Anfragen erst, wenn nach dem Reboot ein gültiger Wert anliegt. Ansonsten würde nicht initialisierte Werte mit 0 beantwortet werden, das ggf. falsch (und gefährlich) wäre.
Der KNX-Stack fragt dazu aber nicht aktiv nach innen bei den Subsystemen (1-wire, Logik, Modbus, etc.) nach.
Daher bleiben Anfragen von EDOMI ggf. für einigen Minuten unbeantwortet, bis der Wert zB vom 1-wire System erstmalig korrekt gesendet wird. Daher ist auch ein zyklisches Senden bei 1-wire zu empfehlen, auch wenn es ein iButton ist. Sonst wird ein abwesender iButton mit 0 initialisiert und sendet nie (da kein change erkannte wird) und sendet dann erstmalig beim Anstecken.
Für Logik ist das ähnlich. Ein Logikausgang wird erstmals an den KNX-Stack übertragen, nachdem die Logik getriggert UND die Sendebedingung erfüllt ist. Bei Logiken, die nicht zyklisch senden, braucht es dazu ggf. eine Mechanismus wie beim "Trigger bei Reboot" (siehe viewtopic.php?f=65&t=1894).
Eventuell ist das hier noch interessant: app.php/kb/viewarticle?a=122
lg
Robert
Das Verhalten ist wie folgt:
Der KNX-Stack antwortet auf Lese-Anfragen erst, wenn nach dem Reboot ein gültiger Wert anliegt. Ansonsten würde nicht initialisierte Werte mit 0 beantwortet werden, das ggf. falsch (und gefährlich) wäre.
Der KNX-Stack fragt dazu aber nicht aktiv nach innen bei den Subsystemen (1-wire, Logik, Modbus, etc.) nach.
Daher bleiben Anfragen von EDOMI ggf. für einigen Minuten unbeantwortet, bis der Wert zB vom 1-wire System erstmalig korrekt gesendet wird. Daher ist auch ein zyklisches Senden bei 1-wire zu empfehlen, auch wenn es ein iButton ist. Sonst wird ein abwesender iButton mit 0 initialisiert und sendet nie (da kein change erkannte wird) und sendet dann erstmalig beim Anstecken.
Für Logik ist das ähnlich. Ein Logikausgang wird erstmals an den KNX-Stack übertragen, nachdem die Logik getriggert UND die Sendebedingung erfüllt ist. Bei Logiken, die nicht zyklisch senden, braucht es dazu ggf. eine Mechanismus wie beim "Trigger bei Reboot" (siehe viewtopic.php?f=65&t=1894).
Eventuell ist das hier noch interessant: app.php/kb/viewarticle?a=122
lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 159
- Registriert: Di Okt 23, 2018 9:27 pm
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 37 Mal
Vielen Dank für die Erklärung, schau ich mir mal an.
Gruß Ben
TWS 960Q ID:359, VPN offen, Reboot erlaubt
TWS 960Q ID:359, VPN offen, Reboot erlaubt