Test Adapter sureflap v3.1.1

[Thomas Braun]

@christianfeu sagte in Test Adapter sureflap v1.0.x GitHub:

Weiterhin stürzt bei mir mir alle 20-30 min der javascript Adapter ab.

Das tut der unter Garantie nicht lautlos.
Schau in

iob logs --watch

uns spiel mit dem Adapter herum.

[christianfeu]

@thomas-braun

ok mache ich. Vielen Dank.

Wollte erstmal rausfinden, ob ich der einzige bin mit Problemen…

[christianfeu]

@christianfeu

Also, in dem Moment wo ich eine Aktion über den SureFlap Adapter ansteuere und ein paar Sekunden später stürzt der Javascript Adapter ab. Habe das jetzt exakt beobachtet. Beim Absturz kommen Meldungen, die mit Redis zusammenhängen.

Hilft das weiter?

2024-02-08 19:57:40.560 - silly: sureflap.0 (102333) doing http request with tag get_data
2024-02-08 19:57:40.560 - silly: sureflap.0 (102333) doing http request with tag get_data
2024-02-08 19:57:50.615 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.inputCount
2024-02-08 19:57:50.716 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.cputime
2024-02-08 19:57:50.717 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.alive
2024-02-08 19:57:51.019 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.cpu
2024-02-08 19:57:51.052 - silly: sureflap.0 (102333) doing http request with tag get_data
2024-02-08 19:57:51.122 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.outputCount
2024-02-08 19:57:51.123 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.eventLoopLag
2024-02-08 19:57:51.632 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.memHeapUsed
2024-02-08 19:57:51.935 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.memHeapTotal
2024-02-08 19:57:52.140 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.memRss
2024-02-08 19:57:52.343 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.connected
2024-02-08 19:57:52.344 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.uptime
2024-02-08 19:57:50.615 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.inputCount
2024-02-08 19:57:50.716 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.cputime
2024-02-08 19:57:50.717 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.alive
2024-02-08 19:57:51.019 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.cpu
2024-02-08 19:57:51.052 - silly: sureflap.0 (102333) doing http request with tag get_data
2024-02-08 19:57:51.122 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.outputCount
2024-02-08 19:57:51.123 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.eventLoopLag
2024-02-08 19:57:51.632 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.memHeapUsed
2024-02-08 19:57:51.935 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.memHeapTotal
2024-02-08 19:57:52.140 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.memRss
2024-02-08 19:57:52.343 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.connected
2024-02-08 19:57:52.344 - silly: sureflap.0 (102333) redis message expired/evicted keyevent@0:expired:io.system.adapter.javascript.0.uptime
2024-02-08 19:58:01.520 - silly: sureflap.0 (102333) doing http request with tag get_data
2024-02-08 19:58:01.520 - silly: sureflap.0 (102333) doing http request with tag get_data

[cooper2k4]

Hallo zusammen,

ich habe seit ca. 3 Wochen das Problem, dass die Protokollierung via SQL-Adapter (sqlite) nicht mehr funktioniert. Ich kann mich leider an keine Änderung an der ioBroker Installation erinnern...

Wenn ich den sureflap-Adapter neustarte wird das Logging automatisch deaktiviert. Ich habe gerade von v1.2.3 auf v2.0.1 aktualisiert. Das hat aber keine Änderung gebracht. Mit anderen Adaptern funktioniert das SQL-Logging ohne Probleme. Liegt es am sureflap- oder SQL-Adapter?

Ich habe schon alles Mögliche probiert (npm cache clean/rebuild, iob Objekte löschen etc.). Weiß jemand noch Rat?

Viele Grüße
Thorsten

--

pi@iobroker:/opt/iobroker $ iob info
Platform       : linux
os             : linux
Architecture   : arm64
CPUs           : 4
Speed          : 1700 MHz
Model          : Cortex-A72
RAM            : 3.7 GB
System uptime  : 1d. 15:52:06
Node.js        : v20.5.1
time           : 1707651469831
timeOffset     : -60
NPM            : 10.4.0
adapters count : 530
Disk size      : 29.1 GiB
Disk free      : 9.2 GiB

[Thomas Braun]

@cooper2k4

Installier nodejs/npm ordentlich.

iob nodejs-update 18

Und künftig die Finger von individuellen Installationen von npm lassen.

[cooper2k4]

@thomas-braun sagte in Test Adapter sureflap v1.0.x GitHub:

iob nodejs-update 18

Danke für den Hinweis. Das ändert aber nichts.

pi@iobroker:/opt/iobroker $ iob info
Platform       : linux
os             : linux
Architecture   : arm64
CPUs           : 4
Speed          : 1700 MHz
Model          : Cortex-A72
RAM            : 3.7 GB
System uptime  : 1d. 20:53:35
Node.js        : v18.17.1
time           : 1707669559211
timeOffset     : -60
NPM            : 10.4.0
adapters count : 530
Disk size      : 29.1 GiB
Disk free      : 9.2 GiB

[Thomas Braun]

@cooper2k4 sagte in Test Adapter sureflap v1.0.x GitHub:

Das ändert aber nichts.

Doch. Dann wäre die Laufzeitumgebung richtig.
Denn
Node.js : v18.17.1
NPM : 10.4.0
ist immer noch falsch.

iob stop
iob fix 
iob nodejs-update 18
iob start

ausführen.

[cooper2k4]

@thomas-braun

Die Laufzeitumgebung sollte jetzt richtig sein. Das ursprüngliche Problem besteht aber weiterhin.

======================= SUMMARY =======================
                        v.2023-10-10


 Static hostname: iobroker
       Icon name: computer
Operating System: Debian GNU/Linux 12 (bookworm)
          Kernel: Linux 6.1.21-v8+
    Architecture: arm64

Installation:           native
Kernel:                 aarch64
Userland:               arm64
Timezone:               Europe/Berlin (CET, +0100)
User-ID:                1000
X-Server:               false
Boot Target:            multi-user.target

Pending OS-Updates:     0
Pending iob updates:    0

Nodejs-Installation:    /usr/bin/nodejs         v18.19.0
                        /usr/bin/node           v18.19.0
                        /usr/bin/npm            10.2.3
                        /usr/bin/npx            10.2.3
                        /usr/bin/corepack       0.22.0

Recommended versions are nodejs 18.19.0 and npm 10.2.3
Your nodejs installation is correct

MEMORY:
               total        used        free      shared  buff/cache   available
Mem:            4.0G        1.6G        679M        2.1M        1.8G        2.4G
Swap:           1.3G        2.1M        1.3G
Total:          5.3G        1.6G        2.0G

Active iob-Instances:   17
Active repo(s): stable

ioBroker Core:          js-controller           5.0.17
                        admin                   6.13.16

ioBroker Status:        iobroker is running on this host.


Objects type: jsonl
States  type: jsonl

Status admin and web instance:
+ system.adapter.admin.0                  : admin                 : iobroker                                 -  enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin
+ system.adapter.web.0                    : web                   : iobroker                                 -  enabled, port: 8082, bind: 0.0.0.0 (SSL), run as: admin

Objects:                10080
States:                 7643

Size of iob-Database:

17M     /opt/iobroker/iobroker-data/objects.jsonl
7.8M    /opt/iobroker/iobroker-data/objects.json.migrated
7.8M    /opt/iobroker/iobroker-data/objects.json.bak.migrated
9.0M    /opt/iobroker/iobroker-data/states.jsonl
5.2M    /opt/iobroker/iobroker-data/states.json.migrated
5.2M    /opt/iobroker/iobroker-data/states.json.bak.migrated



=================== END OF SUMMARY ====================

[Sickboy78]

Hallo @christianfeu

hab grad bei mir getestet und kann sowohl die Klappe als auch die Ausgangssperre per Adapter aktivieren und deaktivieren. Scheint also kein Problem mit der API zu sein.

Dein Log hilft mir leider auch nicht weiter, da ist nichts Ungewöhnliches zu erkennen. Auch nicht welche Aktion du ausführst. Wenn du die Klappe verriegelst, sollte sowas im log stehen:

2024-02-13 19:16:14.717 info lock mode changed to 1
2024-02-13 19:16:12.427 debug changing lock mode to 1...

Kannst du bitte nochmal einen Logauszug machen, wo die Aktion erkennbar ist, die du vor dem Absturz gemacht hast?
Wenn der Adapter neu startet, sollte es solche Einträge im Log geben:

2024-02-13 19:40:11.179 info starting. Version 1.2.3 in /opt/iobroker/node_modules/iobroker.sureflap, node: v18.17.1, js-controller: 5.0.17
2024-02-13 19:40:05.798 info Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2024-02-13 19:40:05.798 info terminating
2024-02-13 19:40:05.798 info everything cleaned up
2024-02-13 19:40:05.797 info Got terminate signal TERMINATE_YOURSELF

Wenn du davon bitte auch nochmal einen Logauszug posten könntest.
Auf was für einem Rechner läuft dein ioBroker? Wieviel Speicher hat der?

VG

[Sickboy78]

Hallo @cooper2k4

interessantes Problem. Ich logge die battery Datenpunkte auch, ohne Probleme.
Kannst du mal bitte posten was nach den disabled logging Einträgen im Log erscheint?
Vorher bitte den Adapter auch auf debug oder silly umstellen.

VG

[christianfeu]

@sickboy78

Hallo,

erstmal danke für deine Antwort. Ich habe im Grunde ja 2 Probleme, die ich mir nicht erklären kann. Um die Sache im 1. Schritt zu vereinfachen, habe ich mir meinen Backup Raspberry 4 genommen und ioBroker frisch installiert und darauf den SureFlap Adapter eingerichtet. Auch hier habe ich das Problem, dass ich den lockmode und curfew nicht ausführen kann (Adapter Version ist unerheblich, es geht mit keiner Version). Wenn ich die Datenpunkte manuell (nicht bestätigt) ändere, bleiben diese auch rot. Egal wie ich das mache, ob manuell oder per VIS oder Skript, die Änderungen werden einfach nicht durchgereicht.

Ich habe grundsätzlich mit dem Adapter Zugriff. Ich kann die Anwesenheit des Tiers per Adapter ändern und mir auch alle Änderungen der History per VIS visualisieren. In den Adapter Einstellungen sehe ich auch das Bild meiner Katze.

Per SureFlap App kann ich alle Funktionen einwandfrei benutzen. Öffnen, Schließen, Zeitregel etc. Alles ohne Probleme. Der Hub ist 4m von der Klappe entfernt. Alles ist korrekt verbunden und eingerichtet. Allerdings habe ich die Hardware erst seit 3 Wochen.

Katzenklappe Firmware: 1.1
Katzenklappe Hardware: 1.2
Hub Firmware: 734.50
Hub Hardware: 3.0

Ich kann mir das einfach nicht erklären. Warum kann ich die Klappe über die App steuern aber nicht über den Adapter?

Das Log bringt wenig interessante Informationen, wenn ich curfew oder den lockmode ändere. Irgendwie hilft das nicht weiter.

Woran kann das liegen?

LOG Auszug bei Änderung lockmode. Danach kommt auch nichts mehr. Adapter ist auf maximale Protokollierungsstufe eingestellt.

LOG-Auszug bei Neustart des Adapters:

Raspberry Info:

[Sickboy78]

Hallo @christianfeu

Der Eintrag "lock mode changed to 0" bedeutet zumindest, dass der Aufruf an die Surepet API erfolgreich war und mit einem 200 OK quittiert wurde. Warum der Datenpunkt dann nicht aktualisiert wird, ist mir rätselhaft.
Ändert sich eigentlich der Zustand in der App?

Ich vermute, dass du eine neue Version der Katzenklappe hast und hier die Datenstruktur abweicht, da deine Versionen (1.1 und 1.2) ganz anders sind als bei mir (335.422 und 9). Um weiter zu analysieren, bräuchte ich aber einen Auszug aus dem Datenverkehr.

Du scheinst dich auszukennen, darum verzichte ich mal auf die Erklärung, wie man sich die Requests im Browser mit den Entwicklertools anschaut. Falls nicht, sag bescheid.

Und zwar hätte ich gerne die Antwort auf den PUT Request für eine Änderung des Lockmode.
Dazu müsstest du im Browser https://surepetcare.io/ aufrufen dich anmelden und ähnlich wie in der App zu den Einstellungen der Klappe gehen und dort die Klappe ver- oder entriegeln.
Da bräuchte ich dann die Antwort auf den PUT request https://app-api.production.surehub.io/api/device/.../control wie im Screenshot als unformatiertes JSON:

Und dann hätte ich gerne noch, wenn du die Übersicht aufrufst https://surepetcare.io/dashboard, die Antwort auf den GET request https://app-api.production.surehub.io/api/me/start (wichtig, der request api/me/start nicht /api/start):

Wichtig, wenn du das JSON (am besten als Textdatei) hier hochlädst, vorher persönliche Daten wie Email entfernen. Alternativ kannst du es mir auch direkt per Email senden: asmoday_666@gmx.de

VG

[cooper2k4]

@sickboy78

Hier ist jetzt der Protokollauszug von Sureflap und SQL mit Silly Log-Level:

2024-02-17 12:21:08.441  - debug: sureflap.0 (1266997) searching and removing of obsolete objects
2024-02-17 12:21:08.442  - silly: sureflap.0 (1266997) deleting obsolete object 'Familie_K_____i.Katzenklappe.led_mode'
2024-02-17 12:21:08.443  - silly: sureflap.0 (1266997) checking for object Familie_K_____i.Katzenklappe.
2024-02-17 12:21:08.443  - silly: sureflap.0 (1266997) deleting obsolete object 'Familie_K_____i.Katzenklappe.control.led_mode'
2024-02-17 12:21:08.443  - silly: sureflap.0 (1266997) deleting obsolete object 'Familie_K_____i.Katzenklappe.control'
2024-02-17 12:21:08.444  - silly: sureflap.0 (1266997) deleting obsolete object 'Familie_K_____i.Katzenklappe.online'
2024-02-17 12:21:08.445  - silly: sureflap.0 (1266997) deleting obsolete object 'Familie_K_____i.Katzenklappe.serial_number'
2024-02-17 12:21:08.445  - silly: sureflap.0 (1266997) deleting obsolete object 'Familie_K_____i.Katzenklappe'
2024-02-17 12:21:08.460  - silly: sureflap.0 (1266997) obsolete object 'Familie_K_____i.Katzenklappe.led_mode' not found
2024-02-17 12:21:08.462  - debug: sureflap.0 (1266997) obsolete object Familie_K_____i.Katzenklappe.control.led_mode found. trying to delete ...
2024-02-17 12:21:08.464  - debug: sureflap.0 (1266997) obsolete object Familie_K_____i.Katzenklappe.control found. trying to delete ...
2024-02-17 12:21:08.465  - debug: sureflap.0 (1266997) obsolete object Familie_K_____i.Katzenklappe.online found. trying to delete ...
2024-02-17 12:21:08.468  - debug: sureflap.0 (1266997) obsolete object Familie_K_____i.Katzenklappe.serial_number found. trying to delete ...
2024-02-17 12:21:08.469  - debug: sureflap.0 (1266997) obsolete object Familie_K_____i.Katzenklappe found. trying to delete ...
2024-02-17 12:21:08.515  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.control.led_mode:null
2024-02-17 12:21:08.517  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.online:null
2024-02-17 12:21:08.522  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.serial_number:null
2024-02-17 12:21:08.527  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868514,"ack":true,"ts":1708168868525,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868525}
2024-02-17 12:21:08.529  - silly: sql.0 (1266515) States user redis pmessage */sureflap.0.Familie_K_____i.Katzenklappe.control.led_mode:null
2024-02-17 12:21:08.531  - silly: sureflap.0 (1266997) States user redis pmessage sureflap.0.*.control.*/sureflap.0.Familie_K_____i.Katzenklappe.control.led_mode:null
2024-02-17 12:21:08.533  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868517,"ack":true,"ts":1708168868528,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868528}
2024-02-17 12:21:08.535  - silly: sql.0 (1266515) States user redis pmessage */sureflap.0.Familie_K_____i.Katzenklappe.online:null
2024-02-17 12:21:08.539  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.control:null
2024-02-17 12:21:08.541  - silly: sql.0 (1266515) States user redis pmessage */sureflap.0.Familie_K_____i.Katzenklappe.serial_number:null
2024-02-17 12:21:08.542  - debug: sureflap.0 (1266997) obsolete object 'Familie_K_____i.Katzenklappe.control.led_mode' deleted
2024-02-17 12:21:08.544  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe:null
2024-02-17 12:21:08.546  - debug: sureflap.0 (1266997) obsolete object 'Familie_K_____i.Katzenklappe.online' deleted
2024-02-17 12:21:08.549  - debug: sureflap.0 (1266997) obsolete object 'Familie_K_____i.Katzenklappe.control' deleted
2024-02-17 12:21:08.551  - debug: sureflap.0 (1266997) obsolete object 'Familie_K_____i.Katzenklappe.serial_number' deleted
2024-02-17 12:21:08.552  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868522,"ack":true,"ts":1708168868549,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868549}
2024-02-17 12:21:08.554  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868539,"ack":true,"ts":1708168868550,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868550}
2024-02-17 12:21:08.595  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868545,"ack":true,"ts":1708168868593,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868593}
2024-02-17 12:21:08.600  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe:null
2024-02-17 12:21:08.606  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.assigned_pets:null
2024-02-17 12:21:08.611  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868599,"ack":true,"ts":1708168868604,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868604}
2024-02-17 12:21:08.620  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868606,"ack":true,"ts":1708168868616,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868616}
2024-02-17 12:21:08.624  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.assigned_pets.Loki:null
2024-02-17 12:21:08.631  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868625,"ack":true,"ts":1708168868629,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868629}
2024-02-17 12:21:08.638  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.battery:null
2024-02-17 12:21:08.639  - info: sql.0 (1266515) disabled logging of sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.battery
2024-02-17 12:21:08.644  - silly: sql.0 (1266515) States user redis pmessage */sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.battery:null
2024-02-17 12:21:08.648  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868638,"ack":true,"ts":1708168868645,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868645}
2024-02-17 12:21:08.653  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.battery_percentage:null
2024-02-17 12:21:08.655  - info: sql.0 (1266515) disabled logging of sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.battery_percentage
2024-02-17 12:21:08.657  - silly: sql.0 (1266515) States user redis pmessage */sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.battery_percentage:null
2024-02-17 12:21:08.662  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868653,"ack":true,"ts":1708168868659,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868659}
2024-02-17 12:21:08.665  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.control:null
2024-02-17 12:21:08.671  - silly: sql.0 (1266515) Objects user redis pmessage */cfg.o.sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.control.curfew:null
2024-02-17 12:21:08.676  - silly: sql.0 (1266515) States user redis pmessage */system.adapter.javascript.0.lastSync:{"val":1708168868665,"ack":true,"ts":1708168868671,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1708168868671}
2024-02-17 12:21:08.677  - silly: sureflap.0 (1266997) States user redis pmessage sureflap.0.*.control.*/sureflap.0.Familie_K_____i.Katzenklappe.Katzenklappe.control.curfew:null

Ich hoffe, das hilft. Da werden Objekte anscheinend aufgeräumt und gelöscht

Viele Grüße

[Sickboy78]

Hallo @cooper2k4,

ich habe einen Verdacht.
Sowohl dein Hub, als auch deine Klappe heißen "Katzenklappe".
Den Namen vom Hub kann man leider imho nicht ändern, aber die Klappe lässt sich in der App umbenennen.
Wenn du ihr testweise mal einen anderen Namen geben könntest, z.B. nur "Klappe" o.ä.
Danach müsstest du entweder alle Objekte unterhalb sureflap.0 löschen und den Adapter neu starten, damit die Struktur neu angelegt wird. Oder alternativ die Instanz löschen und neu hinzufügen.
Und dann prüfen, ob das Problem noch besteht.

Problem ist, dass es vor kurzem eine Änderung in der API gab, wodurch die Geräte (z.B. Klappe) fälschlicherweise direkt unter dem Haushalt erzeugt wurden, statt unterhalb des Hubs. Um das zu korrigieren, habe ich eine Funktion eingebaut, die nach den Geräten unterhalb des Haushalts sucht und, falls es sie findet, wieder löscht.
Jetzt sucht er bei dir nach "Katzenklappe" und findet diese auch. Allerdings handelt es sich aufgrund der Namensgleichheit nicht um die Klappe, sondern um den Hub. Und dann versucht er fälschlicherweise den Hub zu löschen, statt der Klappe. Dadurch wird auch der battery-State gelöscht und somit das Logging deaktiviert.

Ich muss mir mal überlegen, wie ich dieses Problem umgehe, aber temporär sollte es hoffentlich helfen, wenn du unterschiedliche Namen vergibst.

Gruß
Sebastian

[cooper2k4]

@sickboy78

Hallo Sebastian,

super!

Vielen Dank für Deine Arbeit und die Erklärung und Lösung. Das war es. Nach dem Umbenennen der Klappe funktioniert es wieder!

Schönes Wochenende
Thorsten

[christianfeu]

@sickboy78

Hallo,

Problem 1 ist gelöst. Ich kann meine Katzenklappe wieder steuern. Dadurch, dass ich beim Haushalt, beim Hub und bei der Katzenklappe denselben Namen verwendet habe, hat der Aufruf nicht mehr funktioniert.

Vielen Dank für die Unterstützung

[Sickboy78]

Version 2.0.2 zeigt unter movement jetzt auch die device id der benutzen Klappe als last_flap_id. Außerdem wurden zwei Bugs behoben, die nur auftraten, wenn der Hub und die Klappe denselben Namen hatten.
English:
Version 2.0.2 now shows under movement the device id of the last used flap as last_flap_id. In addition, two bugs have been fixed that only occurred if the hub and the flap had the same name.

[Sickboy78]

Mit Version 2.1.0 kann man die History in der Konfiguration ein- und ausschalten und festlegen, wie viele History-Datenpunkte angezeigt werden sollen (max. 25). Standardmäßig ist die History ab sofort deaktiviert. Dies ist nötig, da das Erzeugen der vielen Datenpunkte in der History bei einigen zu starker Last geführt hat, bei manchen sogar zum Absturz des JS-Adapters. Für die meisten war die History eh uninteressant und wer mehrere Klappen hat, für den gibt es seit Version 2.0.1 die movement-Datenpunkte. Wer trotzdem die History benötigt, kann sie in der Konfiguration wieder aktivieren. Auf meinem System hat sie z.B. keine Probleme verursacht. Für die Zukunft werde ich die History wohl umbauen und kompakter gestalten, damit nicht mehr so viele Datenpunkte erzeugt werden.
English:
With version 2.1.0 you can switch the history on and off in the configuration and specify how many history data points should be displayed (max. 25). The history is now deactivated by default. This is necessary because the generation of so many history data points has led to heavy load for some users and even to crashes of the JS adapter for some. For most people the history was of no interest anyway and for those who have several flaps, the movement data points have been available since version 2.0.1. If you still need the history, you can reactivate it in the configuration. On my system for example it did not cause any problems. For the future, I will probably rebuild the history and make it more compact so that not so many data points are generated.

[Sickboy78]

Version 2.1.1 enthält einen Bugfix und 2.1.2 Dependency Updates.
English:
Version 2.1.1 contains a bugfix and 2.1.2 dependency updates.

[Sickboy78]

Sure Petcare hat seine neue App ausgerollt. Soweit ich das sehe, verwendet sie weiterhin die neue API, auf die ich mit version 2.x.x umgestellt habe. Bis auf ein paar Timeouts während der Umstellung ist mir bisher nichts aufgefallen und es scheint alles alles wie gehabt zu funktionieren. Falls euch Probleme auffallen, gerner hier oder auf github Bescheid geben.
English:
Sure Petcare has rolled out its new app. As far as I can tell, it is still using the new API that I switched to with version 2.x.x. Apart from a few timeouts during the cutover, I haven't noticed any problems so far and everything seems to be working as usual. If you notice any problems, please let me know here or on github.