Insider Preview 3 veröffentlicht

Bild

Wir haben seben die Insider Preview 3 zur Version 4.8 veröffentlicht
Komplett überarbeiteter Logik Katalog mit verbesserter Übersicht und Suche für einfachere Auswahl der Lgik Module
Sechs neue Logiken für Farbraum-Umrechnungen (siehe Bild)
Fünfzehn neue Logiken aus der Community
Damit sind es nun 99 Logiken
Einundzwanzig neue winterliche Hintergründe für die VISU
Verbesserte Mouse-Over im VISU Editor für klarere Information
Das HTTP-API Subsystem liefert nun im Header stets Header Access-Control-Allow-Origin = * aus
Der Modbus Register Auswahlassistent erlaubt nun verschiedene Sortierungen beim Anlegen einer Transaktion
Viele Bugfixes


Release Notes: https://elabnet.atlassian.net/wiki/x/AYDD0

AKTION: Wir haben noch viele tolle Updates und 150 Videos (und 800 Wiki Seiten) geplant. Bitte unterstütze uns mit einem Software-Wartungsvertrag, damit wir dieses alles erreichen können. Und damit Dein Server weiterhin Updates, Upgrades und Support erhält. Jetzt in der Aktion schenken wir Dir den Insider Club mit derselben Laufzeit wie der am längsten laufende aktive Wartungsvertrag dazu - bei sofortigem Laufzeitbeginn. Damit profitierst Du auch von einer vorzeitigen Verlängerung. Alle Infos: https://elabnet.atlassian.net/wiki/x/GQB8z

[V2.0 Insider Preview 3.1] Read Request funktioniert nicht (sofort)

Diskussionen über die KNX-Funktionen im Timberwolf Server
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
Antworten

Ersteller
stonie2oo4
Beiträge: 159
Registriert: Di Okt 23, 2018 9:27 pm
Hat sich bedankt: 30 Mal
Danksagung erhalten: 38 Mal

[V2.0 Insider Preview 3.1] Read Request funktioniert nicht (sofort)

#1

Beitrag von stonie2oo4 »

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"):
ets.JPG


Wenn ich in den Gerätemanager von I-Wire gehe, sehe ich den aktuellen Status des IButtons:
ibutton.JPG


Und im Logikmanager wird auch der aktuell richtige Live-Status angezeigt:
tw logik.JPG



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?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Gruß Ben


TWS 960Q ID:359, VPN offen, Reboot erlaubt

Robert_Mini
Beiträge: 3914
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1287 Mal
Danksagung erhalten: 2227 Mal

#2

Beitrag von Robert_Mini »

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
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Ersteller
stonie2oo4
Beiträge: 159
Registriert: Di Okt 23, 2018 9:27 pm
Hat sich bedankt: 30 Mal
Danksagung erhalten: 38 Mal

#3

Beitrag von stonie2oo4 »

Vielen Dank für die Erklärung, schau ich mir mal an.
Gruß Ben


TWS 960Q ID:359, VPN offen, Reboot erlaubt
Antworten

Zurück zu „KNX“