/hmip/0/homes/ stops synchronizing with homematicIP AccessPoint

[PeterSmarthome]

Describe the bug
Refereing to your note: "If you are looking for the information, if the alarm settings are active, you have to check the active status of the group INTERNAL and EXTERNAL, they represent in combination the three alarm states. INTERNAL and EXTERNAL actives means Away, only EXTERNAL active means only Perimeter active."

It looks like the status is not updated when I am using the Homematic app from remote.
It seems to have worked when I used the HomematicIP remote-controller (HmIP-KRCA) on-site (I have not used the app on-site)

To Reproduce
Steps to reproduce the behavior:

1. On-Site using the remote controller (HmIP-KRCA) to activate "Vollschutz". Correctly the object has been updated to "true".
2. Remote using the Homematic App to deactivate the alarm, and switching on the alarm again. Bug: No change in status

Versions:

• Adapter version: 1.22.0
• JS-Controller version: 5.0.19
• Node version: NodeJS v18.19.1
• Operating system: ubuntu linux

[PeterSmarthome]

After I did a reboot of the server it worked. So, it looks like a job for status sync hast stopped to work. I also noticed that /hmip/0/homes/weather has not been updated until the reboot.

Before the reboot I did update NodeJS 18.19.1 -> 18.20.2
Not sure if the reboot or the new version of NodeJS fixed it.

Is there a way to monitor the sync health and trigger a reboot automacilly?
(hmip.0 instance was always shown as "running")

[PeterSmarthome]

Again tonight /hmip/0/homes/ stopped synchronizing the status with my homematicIP AccessPoint. Until then, everything worked fine. A restart of the instance fixed it. So, the issue is not because of the remote-controller and App, but because of the sync-job stopping to work. I will rename this thread to "/hmip/0/homes/ stops synchronizing with homematicIP AccessPoint"

hmip Adapter Version: 1.22.0

CPU: 1,33 %
RAM: 21 %
Betriebszeit: 21h
Verfügbar: 5.0.19
Installiert: 5.0.19
Ereignisse: ⇥12 / ↦13
Plattform: linux
Betriebssystem: linux
Architektur: x64
CPUs: 8
Geschwindigkeit: 800 MHz
Modell: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
RAM: 7.6 GB
System-Betriebszeit: 21:22:18
Node.js: v18.20.2
time: 1715755951749
timeOffset: --
NPM: 10.5.0
Adapter-Anzahl: 539
Datenträgergröße: 455.5 GB
Freier Festplattenspeicher: 445.1 GB
Aktive Instanzen: 12
Pfad: /opt/iobroker/
Betriebszeit: 21:08:54
aktiv: true
_nodeCurrent: 18.20.2
_nodeNewest: 18.20.2
_nodeNewestNext: 18.20.2
_npmCurrent: 10.5.0
_npmNewest: 10.5.0
_npmNewestNext: 10.5.0

[Apollon77]

Please enable debug logging so that we maybe see something in the log when the issue happens again.

[PeterSmarthome]

@Apollon77 did it already but this is all I get (it ist not when the issue occurs - I'll wait until it re-occurs and repost)

[Apollon77]

But post as text please. My OCR skills are good but meehhhhhh ;-))

[Apollon77]

And in fact we need to comparelogs where it worked to log where not and check what happend in between last working and not working

[PeterSmarthome]

Thank you @Apollon77
I did set it into debugging mode, but the file is huge. What should I look for?
I did also implement a node-red flow that restarts hmip, when it's not been updated for longer than 10 mins. But how can I identify a restart in the logs?

[Apollon77]

Hard to dsay ... in fact maybe check for info or waning or error logs that could show a reconnect or such? in fact the logging should change at the time where it broke.

[Tom54497]

Same as post #591

[Tom54497]

See #591 (comment)

[mcm1957]

When diagnosing the problem, please check decription #591 too:

Installed two instances of hmip. In the second one from time to time the actualtemperature value will not be refreshed. It stucks on the same value although looking at the temperature of the HM app it has changed. After restarting the adapter the correct value will show up. Made a workaround that when the value does not change for 24 hours I will get a notification to restart the adapter.

[Apollon77]

Please set loglevel to debug, let it run until it happens and post log minimum 1h before it starts to 1h afterwrads

[mcm1957]

Please retry with 1.26.5

[mcm1957]

Please open a new issue if you still encounter problems and link to this one if applicable.