in der ID-Berechnung trat unter bestimmten Umständen auf 64-bit-Systemen ein Fehler auf. Betroffen sind nahezu alle Module in dieser Library. Dieser Fehler ist mit der neuen Version behoben.
Die neue Version ist wie immer zunächst als Beta im Module-Store erhältlich.
Grüße
Jürgen
Ja das war es. Aber findet der Überlauf nicht schon in IPS beim Datenflow statt?
Ja, im Datenfluss wird ein 32 Bit Integer genommen. Dadurch gibt es einen Überlauf, den es bei 64-Bit-Systemen nicht gibt. Deshalb muss ich für 64-Bit-Systeme den Überlauf nachbilden. Das hatte ich für den Datenfilter auch gemacht, nicht aber für die Ermittlung des betätigten Schalters.
ich jage mal wieder das Phantom.
Für die heisen Tage hab ich mir einen Ablaufplan geschrieben der mir die Rollläden aufgrund bestimmter Regeln auf bestimmte Positionen fährt. Dabei ist es wieder aufgetaucht.
Aktuell betrifft es genau einen Rolladen am Kanal 2 eines FSB14, solange der Rollladen Auf fährt und stoppt passt alles, aber wenn er Ab fährt und stoppt dann passiert es. Er springt auf 100% obwohl er erst auf irgendeiner position <100% steht.
Problem an der Stelle, sobald ich das Debug anwerfe um zu schauen warum es nicht geht, geht es. Ich hab gestern 15min lang hoch und runter gefahren → es ging immer!
2 Stunden später dann einmal übers skript und schon ist er wieder gesprungen.
Aber heute ist mir etwas aufgefallen!
Normal ist es ja so, Meldung mit Fahre zu, danach Stopp mit Fahrzeit
Line 718: HEX: 16.06.2022, 18:31:42 | Parse Buffer | A5 5A 8B 05 02 00 00 00 00 00 00 0C 30 CE
Line 720: HEX: 16.06.2022, 18:31:42 | Parse Chunk | 8B 05 02 00 00 00 00 00 00 0C 30
Line 722: HEX: 16.06.2022, 18:31:44 | Parse Buffer | A5 5A 8B 07 00 16 02 0A 00 00 00 0C 20 E0
Line 724: HEX: 16.06.2022, 18:31:44 | Parse Chunk | 8B 07 00 16 02 0A 00 00 00 0C 20
Einmal ging es nicht, da kam nach der Meldung Fahre Zu eine andere Nachricht die ich nicht verstehe, die aber die ID des FSB-Kanal2 beinhaltet (00 00 00 0C). Daführ fehlte die Stopp + Fahrzeitmeldung im Debug die eigentlich an der stelle hätte kommen müssen wie oben.
Line 738: HEX: 16.06.2022, 18:32:32 | Parse Buffer | A5 5A 8B 05 02 00 00 00 00 00 00 0C 30 CE
Line 740: HEX: 16.06.2022, 18:32:32 | Parse Chunk | 8B 05 02 00 00 00 00 00 00 0C 30
Line 750: HEX: 16.06.2022, 18:33:04 | Parse Buffer | A5 5A 0B 07 00 00 00 0C FF 93 24 81 00 55
Line 752: HEX: 16.06.2022, 18:33:04 | Parse Chunk | 0B 07 00 00 00 0C FF 93 24 81 00
Hast du eine Idee was das ist?
Viele Grüße
Rolf
Das ist ein merkwürdiger Fehler. Wenn die DeviceID 00 00 00 0C ist, dann darf sie auch nur erkannt werden, wenn sie, wie in Line 738 fett markiert, positioniert ist. In Linie 752 ist die 00 00 00 0C in der Datenposition. Die DeviceID ist FF 93 24 81.
Ich gehe davon aus, dass du die Melde-ID in der Instanz mit mit 00 00 00 0C konfiguriert hast. In diesem Fall dürften die Daten gar nicht in der Instanz ankommen. Daran kann es also bei korrekt konfigurierter Instanz gar nicht liegen.
Um dem Problem näher zu kommen, solltest du im Debugfenster der betroffenen Shutter-Instanz an Datei schicken aktivieren. Dann kannst du, wenn das Problem wieder auftritt, die Datei nach dem Fehler durchflöhen.
Grüße
Jürgen
Hi Jürgen,
Das Phantom ist leider entwischt 
Folgendes hat sich heute ergeben:
Die 00 00 00 0C sind zufällig der Wert (0W) den mein FSR61VA ( FF 93 24 81) zyklisch sendet. Es passt nur zufällig genau vom zeitlichen Ablauf hat aber wie vermutet nichts damit zu tun.
Übeltäter ist tatsächlich der FSB14 selbst, heute hatte er einen schlechten Tag und nicht nur gelegentlich sondern ganz oft bei Ab nicht die Fahrzeit sondern nur ein 50 für geschlossen geschickt. Allerdings nur für den einen Kanal und irgendwie fehlte das auch im Debug 
Ich hab den Aktor mal resettet, danach hat er brav die Fahrzeiten bei Ab geschickt, mal sehen wie lange es dabei bleibt.
Dabei hat sich eher zufällig noch gezeigt wie unzuverlässig das LAN Gateway ist. Dazu aber wo anders mehr.
Trotzdem Danke!!
Grüße Rolf
Dear Jürgen,
I have been running your update sinced april till now. It works stable and no errors anymore.
Many thanks for update!
Kind regards,
Jeroen
Hallo Leute,
ich habe den Threat bereits verfolgt und das Problem scheint insofern bekannt zu sein, was allerdings mit einer neuen Version eliminiert wurde. Allerdings ist das Problem bei mir nach wie vor präsent, meine FSB14 Aktoren melden geben keine Positionsmeldungen in der Instanz zurück. Hängt wohl mit der ID Berechnung und dem 64-bit System zusammen. Allerdings ging es bis vor wenigen Wochen noch tadellos.
Dementsprechend bin ich etwas verwundert. Ich habe auch FSB61 Aktoren welche mit dem Modul einwandfrei Ihre Position zurückmelden.
Im Debug sehe ich auch kein Response, sondern nur Sendebefehle. Lediglich wenn ich auf „Suche ID“ bin, kommt im Debug entsprechendes an.
Was kann die Ursache hierfür sein? Haben andere ebenfalls das Problem?
VG Heiko
Hallo Heiko,
das 64-bit-Problem wurde bereits mit der V3.01 gefixt und wie du schreibst, funktioniert die Datenweiterleitung bei den FSB61 ja auch. Die Ursache muss also woanders zu finden sein. Hast du ggf. eine falsche Rückmeldeadresse eingetragen?
Grüße
Jürgen
Hallo Jürgen,
nein die Rückmeldeadresse passt, diese wird ja ebenso bei der ID Suche gefunden. Im Debug der Instanz meldet sich bei der Suche ID der FSB14 mit seine Rückmeldeadresse, nur wenn ich Steuerbefehle setze meldet er sich in der Instanz nicht. Es kommt kein „Receive“ an.
Aber in dem Debug des EnOcean Gateways wiederum sehe ich eine Antwort des Aktors. Auch blinkt die LED des Aktors nach einem Steuerbefehl auf, welche signalisiert, dass die Rückmeldung des Aktors erfolgt.
Aber die FSB14 Instanz interessiert das leider nicht.
Bei den FSB61 Aktoren funktioniert das einwandfrei. Ich bin irgendwie ratlos, zudem es ja in der Vergangenheit immer funktioniert hat.
Wenn du in der FSB14-Instanz etwas änderst und dann auf Änderungen übernehmen drückst, dann kommt im Debug-Fenster folgende Meldung
27.10.2022, 13:30:18 | Filter | .*\"DeviceID\":8,.*
Wie sieht diese bei dir aus?
Wie sehen die empfangenen Daten des dazupassenden FSB14 aus, wenn Du auf Suche Melde-ID drückst?
27.10.2022, 13:54:30 | Filter | ."DeviceID":-636747,.
Die Melde-ID des FSB14 Aktors in dem Falle lautet FFF648B5.
Wie sehen die empfangenen Daten des dazupassenden FSB14 aus, wenn Du auf Suche Melde-ID drückst? Ich brauche den zugehörigen Datensatz.
27.10.2022, 14:26:51 | Receive | {"DataByte0":2,"DataByte1":0,"DataByte10":0,"DataByte11":0,"DataByte12":0,"DataByte2":0,"DataByte3":0,"DataByte4":0,"DataByte5":0,"DataByte6":0,"DataByte7":0,"DataByte8":0,"DataByte9":0,"DataID":"{DE2DA2C0-7A28-4D23-A9AA-6D1C7609C7EC}","DataLength":1,"Device":246,"DeviceID":8,"Status":48}
Hier die empfangen Daten:
27.10.2022, 14:59:28 | Receive | {"DataByte0":10,"DataByte1":1,"DataByte10":0,"DataByte11":0,"DataByte12":0,"DataByte2":0,"DataByte3":0,"DataByte4":0,"DataByte5":0,"DataByte6":0,"DataByte7":0,"DataByte8":0,"DataByte9":0,"DataID":"{DE2DA2C0-7A28-4D23-A9AA-6D1C7609C7EC}","DataLength":4,"Device":165,"DeviceID":4294330549,"Status":1}
die Device ID 4294330549 dort im Datensatz entspricht auch der HEX FFF648B5 Rückmelde ID
ok, gucke ich mir an. Da sollte es in Kürze eine Lösung geben.
In IP-Symcon Version 6.3 wird die Berechnung der DeviceID von 32- auf 64-bit umgestellt. Mit diesem Update ist das Modul kompatibel zur neuen Berechnung. (@paresy Ich habe nirgends einen Hinweis auf diese Änderung finden können. Kannst du das bitte in die Changelogs aufnehmen? Da sind sicherlich auch andere Module betroffen.)
Für alle Nutzer des Shutter-Moduls gibt es noch ein Goody dazu: Die Rolladenposition wird jetzt während des Betriebs einmal pro Sekunde aktualisiert. Die Aktualisierung ist nur eine Prognose der tatsächlichen Position und kann minimal abweichen. Diese Abweichung wird aber korrigiert, sobald der Rolladen steht.
Die neue Version ist wie immer zunächst als Beta im Module-Store erhältlich.
Grüße
Jürgen
Moin,
die neue Version ist super geworden, auch die Positionsangabe bei Betrieb ist ein echter Mehrwert.
Nun klappt auch alles bei mir wieder einwandfrei. Lediglich der oben besagte Aktor mit der Rückmeldeadresse FFF648B5 will nicht. Er erhält auch nun sauber einen Receive aber innerhalb der Instanz tut sich nichts, weder die dynamische Positionsangabe noch der Aktionsstatus und die finale Rückmeldung des Aktors. Aber wie bereits erwähnt, ist dieses Verhalten nur bei dieser einen Instanz zu beobachten, der Rest läuft super.
VG Heiko
01.11.2022, 09:41:35 | Receive | {"DataByte0":8,"DataByte1":0,"DataByte10":0,"DataByte11":0,"DataByte12":0,"DataByte2":0,"DataByte3":0,"DataByte4":0,"DataByte5":0,"DataByte6":0,"DataByte7":0,"DataByte8":0,"DataByte9":0,"DataID":"{DE2DA2C0-7A28-4D23-A9AA-6D1C7609C7EC}","DataLength":4,"Device":165,"DeviceID":4294330549,"Status":1}
schön, dass es jetzt funktioniert. Wie sieht es bei dem Problemaktor aus? Erhälts Du nur Daten für
"Device":165
oder auch für
"Device":246
Letzteres ist der Datensatz, der die dynamische Positionsangabe realisiert.
Grüße
Jürgen
Hallo Jürgen,
sorry ich war ein paar Tage verreist, deswegen die späte Antwort. Bei dem Problemaktor erhalte ich nur Daten für „Device“:165 nicht für „Device“:246. Bei den anderen Aktoren erhalte ich überall „Device“:246.
VG