Stuck in "DEV UPDATING X" after existing Installer Mode

[rexchoppers]

Description:

I'm using https://github.com/msp1974/visonic_proxy with this integration on a Powermaster 10. Everything is working correctly when the integration is first initialised. However, I'm encountering a small issue. When I perform some configuration and exit "Installer Mode", the proxy becomes very busy, and my panel seems to be stuck in a look of "DEV UPDATING 000"

It may go to "DEV UPDATING 016" -> "DEV UPDATING 015" -> "DEV UPDATING 014" and then back to "DEV UPDATING 016" constantly. The only way to prevent this is to disable and re-enable the integration in HA.

Steps To Reproduce:

1. Setup Visonic Proxy
2. Wait for panel to connect to proxy
3. Init Visonic HA Integration
4. See the screen go from "DOWNLOADING" for a few seconds to "DEV UPDATING 016" -> "DEV UPDATING 015" -> "DEV UPDATING 014" and it'll countdown
5. Panel will then show ready
6. Go into Installer Mode
7. Exit Installer Mode
8. For a few seconds, all may appear fine and then the "DEV UPDATING 016" -> "DEV UPDATING 015" loop will occur.

What seems to fix the issue

1. Disable HA integration
2. Wait a minute for all the requests from the panel to time out
3. Re-enable the HA integration. This will perform the init again process again but will not loop

[rexchoppers]

Error (Un-sure if this is related)

This error originated from a custom integration.

Logger: custom_components.visonic.pyvisonic
Source: custom_components/visonic/pyvisonic.py:2878
integration: Visonic Intruder Alarm (documentation, issues)
First occurred: 21 July 2025 at 18:13:45 (46 occurrences)
Last logged: 14:07:18

5 is not a valid DataType
Traceback (most recent call last):
  File "/config/custom_components/visonic/pyvisonic.py", line 2878, in data_received
    self._handle_received_byte(databyte)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/config/custom_components/visonic/pyvisonic.py", line 3042, in _handle_received_byte
    processReceivedMessage(ackneeded=self.pmCurrentPDU.ackneeded, debugp=self.pmCurrentPDU.debugprint, msg=self.pmCurrentPDU.msg, data=self.ReceiveData)
    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/visonic/pyvisonic.py", line 2933, in processReceivedMessage
    self.packet_callback(data)
    ~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/config/custom_components/visonic/pyvisonic.py", line 3927, in _processReceivedPacket
    pushchange = dm.func(packet[2:-2])    # Use the return value if the function returns
  File "/config/custom_components/visonic/pyvisonic.py", line 5349, in handle_msgtypeB0
    self.processChunk(chunk)
    ~~~~~~~~~~~~~~~~~^^^^^^^
  File "/config/custom_components/visonic/pyvisonic.py", line 4945, in processChunk
    self._extract_42_data(ch)
    ~~~~~~~~~~~~~~~~~~~~~^^^^
  File "/config/custom_components/visonic/pyvisonic.py", line 4757, in _extract_42_data
    log.debug(f"[_extract_42_data]               {dataContent=}   {max_data_items=}   {data_item_size=}   {start_entry=}   { DataType(datatype) }   {byte_size=}   {no_of_entries=}")
                                                                                                                             ~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/enum.py", line 726, in __call__
    return cls.__new__(cls, value)
           ~~~~~~~~~~~^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/enum.py", line 1201, in __new__
    raise ve_exc
ValueError: 5 is not a valid DataType

I will obtain a log file now

[rexchoppers]

Sod's law I've not been able to replicate this as soon as I want logs for it. I will leave the issue open and keep trying

[davesmeghead]

Hi, I've just made a Github 0.12.1.2 release (but not a HACS release so you'll need to download the zip file to install it).
It fixes the ValueError: 5 is not a valid DataType error but probably not your initial problem.
Can you create a log file for the initial problem please i.e. enter Installer on the panel and then exit. I probably need arounf 5 or 10 minutes before and after.

[rexchoppers]

Hi @davesmeghead I've downloaded 0.12.1.2 and it seems to be working okay actually. I'm going to do some further testing Today and close this issue if I can't replicate it again.

[rexchoppers]

Hey @davesmeghead I've reset the integration as I was having other issues with HA. This issue is more intermittent than I first thought and not particularly reproducible.

HA Log:

home-assistant_visonic_2025-07-23T12-39-16.229Z.log

It looks like whenever it's pulling data from the panel as in a reload, new integration setup etc... It's getting stuck in an endless loop

[davesmeghead]

There seems to be 2 problems, I think both are indirectly related to using the proxy

1. Getting the zone names is actually easier with the proxy than without. I've hopefully fixed this.
2. Setting the time in the panel takes longer and therefore gets out of sync.

To explain the last one, and this gets complicated:

• With MOTION sensors i.e. PIR sensors, all I get is the time and date of the last update.
• The panel tells me of the update (it actually tells me to ask the panel for the update) so I get the time/date,
• I then compare it to the time/date of the previous and
• Then decide whether to indicate a triggered sensor in HA.
• So I monitor the panel time to make sure it doesn't drift, and it doesn't normally, many weeks without needing to set/update the panel time normally
• Once set, even restarting HA/Integration it's already set from the last time and doesn't drift by much.

If I detect a drift of more than 3 seconds (compared to local time) then I set the panel time according to local time. And this normally works, like I said every few weeks or so.

The issue with the proxy is that it introduces a delay in both getting and setting the time, especially if it's busy with the visonic server. So the messages to set the time get delayed, and if delayed by more than 3 seconds then the next time I detect that the time is wrong and try to set it again, and so the loop begins! i.e. By the messages getting delayed, it's setting the wrong time in the panel, I detect it as wrong and try to set it ... again.

After all that, I've never seen this problem with my test panel using the proxy, but maybe I've never run it for long enough.

In the zip file below I've fixed 1. and made the time setting messages "Immediate" rather than "Urgent" to see if it makes a difference, can you please give it a try and upload another log file. The software release numbers are the same as the main release, this is an unofficial dev release only.

visonic.zip

One possible different way of doing it is to save the panel time and the offset inside the integration and use that instead of setting the local time in the panel. Let me think about this a bit more.

EDIT: Not 3 seconds, it's 4 seconds. Line 4550 tolerance = 4 # seconds

[rexchoppers]

@davesmeghead That makes a lot of sense. Thank you so much for looking into this and clarifying those issues. I'll upload this ZIP into my HA and see if that helps any. I appreciate the time you take to look into these issues.

This does make sense as my house is kitted out with a lot of devices e.g motion, smoke + heat, door contacts, glass break, a repeater, a siren and several panels 😅

[davesmeghead]

OK, that's no problem, just let me know how you get on with it.
The information that I forgot to include .... to set the time in the panel I have to put the panel in to DOWNLOADING state, that's why you'll see it changing on the panels display.

[rexchoppers]

Hi @davesmeghead - Every appears to be working really well so far. Will do a few more days of testing but it's working much better so far

[davesmeghead]

Hi, I've made a few updates if you're able to give it a try for this issue
visonic.zip

[rexchoppers]

@davesmeghead Hi - Currently testing this build now

[davesmeghead]

I've just created a HACS release but it's pretty much the same as what you've got on test, and problems then please let me know.

[rexchoppers]

Hey @davesmeghead thank you for your effort on this. I will keep this ticket open and do a final bit of testing as I've managed to replicate this issue again but not in the same use case as before. Think it's probably only minor. I'll report back

[rexchoppers]

@davesmeghead Still not been able to replicate this again now - Will give it a few more days but if I can't, I'll close the issue

[davesmeghead]

OK, good to know, thanks for the update