Weird behaviour after network update #163

ondrejmirtes · 2024-02-08T16:39:49Z

Hi,
the behaviour might not be a fault of this integration but to me it felt like the best place to discuss this. So I'm sorry if it's inappropriate, but I have no other way to debug it.

My setup is described here in this comment (#137 (comment)).

Until recently it worked well. But after my eero router updated to the latest version, weird things started happening. Sometimes I'm not able to control the alarm control panel, or HA does not report open/closed windows correctly.

The weirdest thing happened this morning. The wireless keyboard (I think it's JA-80F) reported about "active output PGX" ("aktivní výstup PGX" in Czech) and in turns about open window sensors, and beeping at the same time about every second. It blocked any interaction with it so I was not able to disarm the alarm from the keyboard.

Disarming from HA also did not work. It says "armed away" and when I tried to disarm it, it said "Disarming" for about a second and then went back to "armed away" immediately.

I fixed it by restarting the USR-W610 remotely.

But the other problems still persist - late reactions, HA does not notice opening/closing of windows etc.

It seems weird to me that all of this behaviour would be caused by something faulty about Wi-Fi though. When I try to load the USR-W610 web UI, it loads immediately. And if there were Wi-Fi problems, the serial device should not somehow flood the alarm with weird messages that would make it misbehave, right?

In HA logs I get errors like:

connection failed, reconnecting
no accepted message for sequence:0 received
Invalid CRC for 8c ed 40 10 00 01 08 00 0a 5b ff

I'm not sure how common they were before these problems started happening.

Thank you for any pointers.

mattsaxon · 2024-02-08T16:43:09Z

As a guess I would consider signal interference.

ondrejmirtes · 2024-02-08T16:44:15Z

What does it mean and what could I do about it?

mattsaxon · 2024-02-08T16:46:02Z

Move the devices apart to stop various electrical devices interfering with each other?

For example is your WiFi router very close to your control panel?

ondrejmirtes · 2024-02-08T16:59:55Z

No, it's not. USR-W610 is installed directly in the control panel, but there are no other devices near it. I could move some wires around in that box but not sure if it's going to help.

mattsaxon · 2024-02-08T17:51:59Z

Sorry, I've no idea then. Seems a wiring fault of some kind from what you describe. The integration hasn't changed has it? Nor has any of your HA/Jabloron setup

Note the error you see in the logs are not uncommon, I get them a fair amount

ondrejmirtes · 2024-02-09T16:47:57Z

I've tried to connect the control panel a to a different W610 device (I've got two). The behaviour didn't change. I feel like it's consistent and reproducible now (the same thing happens every time).

I've recorded a video what the keypad does (it cycles through all active sensors - open windows). So it's usable only when there's no active sensor or only a single one. It's not supposed to do this.

IMG_5792.mov

Home Assistant notices immediately when a window opens, but no longer notices when a window closes (the state remains "open" in HA).

I'm gonna disconnect W610 and hopefully this behaviour disappears, otherwise there's obviously something wrong with the control panel itself and not just with W610/Home Assistant.

One idea my wife had - 2 days ago I tripped a circuit breaker because I was trying out my multimeter in one of the electrical sockets and I had it set to a wrong setting. Maybe that could have somehow damaged the device.

ondrejmirtes · 2024-02-10T19:24:34Z

So when the W610 is disconnected, the control panel no longer does this, it behaves as usual.

I feel like the behaviour now is too regular to be caused by some "analog" stuff like interference.

Is it possible that one of the loops executed here

jablotron80/custom_components/jablotron80/jablotron.py

Lines 2617 to 2619 in 5b1c0fb

    
           loop.create_task(cu.processing_loop()) 
        
           loop.create_task(cu.status_loop()) 
        
           loop.create_task(cu.read_settings())

is responsible for this behaviour? E.g. the integration tries to read the state of the system, which sensors are active etc., and causes the same information to cycle on the keyboard...

mattsaxon · 2024-02-10T19:33:51Z

Agree with you. So can you pinpoint what has changed to cause this, it's obviously not your wifi upgrade now.

My recollection of the integrations activity is that it is effectively pushing the ? Key multiples times to work out state

ondrejmirtes · 2024-02-10T19:55:05Z

I can't think of anything, besides tripping the circuit breaker for the whole home once, and updating this integration from 0.33 to 0.34. Maybe some cosmic rays flipped a bit somewhere which is causing all of this havoc for all I know :)

To reiterate all things that are right/wrong:

Initial setup works the same way, correctly loads the number of wireless devices 👍
Arming alarm through HA works 👍 , but disarming does not work 👎
HA integration immediately notices that a window gets open 👍 but no longer notices the window gets closed 👎
When I open the keypad and the alarm is disarmed, the keypad cycles through all active sensors 👎 It makes it impossible to operate the keypad - I can't arm the alarm from it.
When I open the keypad and the alarm is armed, the keypad cycles through all active sensors + there's one more step in the loop that shows "Active output PGY". 👎 It makes it impossible to operate the keypad - I can't disarm the alarm from it. I solve this by sending a text message to disarm the alarm that way.

What can I do as a next step next weekend is to connect the W610 to the control panel but shut down HA, to see if the device communicates with something to cause this behaviour, or if it's enough that it's just connected to cause the keypad to misbehave.

I'm now reading through the JA-80 manual to see if there's something about the keypad behaving this way, no hits so far.

mattsaxon · 2024-02-10T19:59:33Z

Can i suggest you downgrade the integration, that's the most likely issue!

ondrejmirtes · 2024-02-10T20:10:11Z

I completely discarded that idea because the commit (5b1c0fb) looks just like changing some constants for other constants, and I also don't think the problems started immediately after that :) But I'm going to try it and report back.

mattsaxon · 2024-02-10T20:26:43Z

Ah i see, is it possibly an HA upgrade that caused the change of behaviour then?

ondrejmirtes · 2024-02-10T20:30:46Z

Yeah, I also updated HA meanwhile, unfortunately can't tell which update happened on which day, AFAIK there's no log for that. Gonna keep digging :)

ondrejmirtes · 2024-02-20T16:54:04Z

Alright, I was getting ready to create a 2nd HA instance that I'd try different HA versions with to pinpoint the problem, but as a first step I updated my main instance from 2024.1.5 to 2024.2.2 and it looks fine for now. I'll keep you updated if the problem returns.

I'll close the issue in a week if it remains stable. Thanks for now!

ondrejmirtes · 2024-02-20T17:03:30Z

I'm sorry, my optimism was a little premature, it's back to the previous behaviour...

ondrejmirtes · 2024-02-21T21:22:20Z

When looking at this manual, do you think there are some settings for the control panel that would be incompatible with this integration? https://www.jablotron.com/en/about-jablotron/downloads/?filename=JA-80K_EN_MKE51801.pdf&do=downloadFile

Like "Triggered detector indication" or "Permanent alarm status display for a set system"...

mattsaxon · 2024-02-21T21:31:58Z

Possibilities, but have you changed these settings recently? Always most likely is this is a change related, just trying to work out what has changed and go from there

ondrejmirtes · 2024-02-21T21:37:17Z

It's driving me crazy. I don't remember changing anything when it stopped working. I only know about updating WiFi router and HA itself.

I'm currently trying it on a fresh HA instance on various older and newer versions but it's still behaving wrongly...

ondrejmirtes · 2024-02-21T21:43:00Z

So the U+, GND, A, B ports on the central unit board that W610 connects to are the same that a wired keypad is supposed to be connected to, right? So the serial device is basically simulating a wired keyboard through a serial RS485 connection, right?

I don't know what kind of commands it receives and sends in order to do its job, but it looks like it's sending a command to cycle through all active sensors, which shows up on my wireless keypad when I open it. That definitely must be happening in the integration I think?

Anyway, I don't feel like I'm going to be worrying about this much longer, I loved it when it worked but now I'm just losing my mind over it.

mattsaxon · 2024-02-21T21:47:53Z

Correct on most points.

The cycle is the equivalent of pressing the ? Key on the keyboard, it does that to read the error status.

We could disable that, but it will impact functionality.

The Q we need to find out is why your keyboard gets into a state that this happens.

If you press the ? Key manually what happens?

ondrejmirtes · 2024-02-21T21:57:53Z

I really appreciate your help.

Yes, if I stop HA and press ? repeatedly on the wireless keypad it looks exactly what's it doing on its own when I start HA with the integration.

So it should not be doing that - state of one keyboard should not influence other keyboards? But for example if I connect to OLink and do stuff there I also here the keyboard beeping.

Additionally the integration can detect open windows immediately but not closing them. This also used to work and I don't know why it does not anymore (why the integration does not receive this information).

mattsaxon · 2024-02-21T22:02:51Z

No it should do it, there is only a single system and it can only have one state, so anything done by HA or Olink will show.

However it should only cycle infrequently. I don't recall exactly the logic, we wrote this some years ago!

ondrejmirtes · 2024-02-21T22:05:25Z

Alright, so it's doing it more often than it should. Anything I can do to debug it? Basically to log all in/out communication? So you can see what's wrong?

mattsaxon · 2024-02-21T22:10:59Z

I'll need to take some time to reacquaint myself with the integration and how it works, and I don't have time just at the moment.

If it's cycling too much and this is breaking the system, probably best to turn off the cycling.

Can you code in Python, it's not configurable as far as I recall

ondrejmirtes · 2024-02-21T22:15:58Z

Yeah sure I can, I'm a PHP guy but my bachelor thesis was in Python 😊

ondrejmirtes · 2024-02-22T07:44:00Z

So I started debugging what's going on. And yeah, the integration sends the "Details" command every second. Because of this piece of code:

		elif activity == 0x16:
			activity_name = 'Triggered detector (multiple)'
			# multiple things are active
			if detail == 0x00:
				# no details... ask..
				LOGGER.debug(f'No details, ask... {data}')
				self._send_device_query()
			else:
				self._activate_source(detail)
				self._confirm_device_query()

I've added the debug statement there. This is what it logs before sending the command:

No details, ask... b'\xed@V\x00\x01\x00\x00\x00m\xff'

So for some reason we're not getting the details we should.

ondrejmirtes · 2024-02-22T08:18:36Z

Maybe the issue is that the activity 0x16 is received every second and should not be, and that might be the root cause, but we're in the area of guess work how the control panel should behave...

mattsaxon · 2024-02-22T08:51:39Z

I'll need to take a look to see how mine behaves.

My recollection is that it shouldn't be sending every second.

I've noted that I'm not on the latest version of the integration however.

Let me check what is going on here..... possibility the coming weekend

ondrejmirtes · 2024-02-24T17:51:57Z

I've been debugging a little bit more and I added this line:

LOGGER.info(f'Received state {hex(status)}')

At the beginning of _process_state. And it's been logging 2024-02-24 18:46:00.094 INFO (MainThread) [custom_components.jablotron80] Received state 0x40 (DISARMED) multiple times a second. Not sure if that's normal or not.

mattsaxon · 2024-02-24T18:00:01Z

Yep the state comes very frequently. It's broadcast constantly as you are seeing

mattsaxon · 2024-02-25T13:44:10Z

The debug info that would be useful during this is 'info' level logging. You need to enable this in configuration.yaml.... here is mine during such a detector activation

HALog.txt

ondrejmirtes · 2024-02-25T14:07:54Z

Are you talking about the "button.ja_80k_query_button"? I don't see another button.

When I press it in HA then the keyboard does the same thing. But it doesn't log "Message changed" because at that point it already noticed that the window is opened so "Message changed" appeared automatically before that.

So this is how it looked like when I opened the windows:

2024-02-25 14:55:46.649 INFO (MainThread) [custom_components.jablotron80] JablotronStatusText(3): message changed from  to Triggered detector
2024-02-25 14:55:46.649 INFO (MainThread) [custom_components.jablotron80] Status: 0x40, 01000000
2024-02-25 14:55:46.946 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] received record: ed 40 50 00 01 00 00 28 2c ff
2024-02-25 14:55:46.947 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] Forwarding 1 records
2024-02-25 14:55:46.948 INFO (MainThread) [custom_components.jablotron80] Received 1 records
2024-02-25 14:55:46.949 INFO (MainThread) [custom_components.jablotron80] Status: 0x40, 01000000
2024-02-25 14:55:46.998 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] received record: ff
2024-02-25 14:55:46.998 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] Forwarding 1 records
2024-02-25 14:55:46.999 INFO (MainThread) [custom_components.jablotron80] Received 1 records
2024-02-25 14:55:47.000 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] received record: a0 ff
2024-02-25 14:55:47.001 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] Forwarding 1 records
2024-02-25 14:55:47.002 INFO (MainThread) [custom_components.jablotron80] Received 1 records
2024-02-25 14:55:47.002 INFO (MainThread) [custom_components.jablotron80] Keypad Beep: 0xa0, 1 subtle (short) beep triggered
2024-02-25 14:55:47.106 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] received record: ed 40 50 15 01 00 00 00 3a ff
2024-02-25 14:55:47.107 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] Forwarding 1 records
2024-02-25 14:55:47.108 INFO (MainThread) [custom_components.jablotron80] Received 1 records
2024-02-25 14:55:47.108 INFO (MainThread) [custom_components.jablotron80] JablotronDevice(21): active changed from False to True
2024-02-25 14:55:47.109 INFO (MainThread) [custom_components.jablotron80] JablotronStatusText(3): message changed from Triggered detector to Triggered detector, 21:serial 01667955

This is how it looked like when I pressed the query button (while the window was open):

2024-02-25 14:56:05.874 INFO (MainThread) [custom_components.jablotron80] Keypad Beep: 0xa0, 1 subtle (short) beep triggered

And this time it even noticed the window closing which I haven't seen in a long time!

2024-02-25 14:56:51.640 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] received record: ed 40 40 00 01 00 00 28 1e ff
2024-02-25 14:56:51.641 INFO (ThreadPoolExecutor-0_0) [custom_components.jablotron80] Forwarding 1 records
2024-02-25 14:56:51.641 INFO (MainThread) [custom_components.jablotron80] Received 1 records
2024-02-25 14:56:51.642 INFO (MainThread) [custom_components.jablotron80] JablotronDevice(21): active changed from True to False
2024-02-25 14:56:51.642 INFO (MainThread) [custom_components.jablotron80] JablotronStatusText(3): message changed from Triggered detector, 21:serial 01667955 to 
2024-02-25 14:56:51.642 INFO (MainThread) [custom_components.jablotron80] Status: 0x40, 01000000

But the thing is that the connection crashed right afterwards:

2024-02-25 14:57:07.612 ERROR (ThreadPoolExecutor-0_0) [custom_components.jablotron80] Unexpected error: read failed: socket disconnected
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/serial/urlhandler/protocol_socket.py", line 171, in read
    raise SerialException('socket disconnected')
serial.serialutil.SerialException: socket disconnected

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/config/custom_components/jablotron80/jablotron.py", line 749, in read_send_packet_loop
    records = self._read_data()
              ^^^^^^^^^^^^^^^^^
  File "/config/custom_components/jablotron80/jablotron.py", line 896, in _read_data
    data = self._connection.read_until(b'\xff')
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/serial/serialutil.py", line 663, in read_until
    c = self.read(1)
        ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/serial/urlhandler/protocol_socket.py", line 178, in read
    raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: socket disconnected

And filling my logs with megabytes of these messages until I restart HA and then it works again for a while. So it suggests something is definitely wrong with my equipment.

mattsaxon · 2024-02-25T14:15:04Z

OK, so apart from the crash, your behaviour is correct.

A couple of things, you have many more info messages that I have, not sure why this is.... I am running version 0.32 (I haven't upgraded the last 2 times). Perhaps this is it, what version are you running?

Secondly, given you have this connection issue, I think this is the problem.... you have the setup and the skills to debug this and find a retry approach that may work in re-establishing the connection without restarting HA. In my experience these are hard to recover from, but impossible for me to deal with given I don't have the same issue occurring. I'm happy to try to give you some direction about what to try.... bottom line, you need to try rereading, then disconnecting/reconnecting etc.

ondrejmirtes · 2024-02-25T14:24:01Z

The logging can be seen in the source code here and it's probably in my log because I enabled "Verbose connection logging" in the integration configuration.

It's weird the connection drops because everything else about my network is super stable. I also made sure W-610 is not hopping between access points, pinning it to a single BSSID.

And also the connection dropping is a different issue than I had before - the connection didn't drop but also it didn't see me closing the window immediately. And as a reminder - the integration worked flawlessly the first few weeks. Strange stuff :)

Next I'll probably try to switch W-610 with the JA-82T cable and Raspberry Pi.

mattsaxon · 2024-02-25T14:27:27Z

That's a good approach, I have such a setup, it was what I originally had before I moved to remote. I only did it for convenience given location of my control panel which made using OLink inconvenient.

ondrejmirtes · 2024-03-02T14:32:02Z

Alright, so instead of W-610 and wires connected to A and B, I've bought JA-82T USB cable and connected it to Raspberry Pi inside the control panel, and I used usbip to bring the device over to the integration running on a different PC.

And the integration is behaving exactly the same! It sees windows opened immediately, but doesn't see them closing + it still cycles through all active sensors on the keypad.

So these devices involved I just replaced weren't the problem...

mattsaxon · 2024-03-02T14:38:12Z

Ok, a couple of questions....

Can you explain to me how I can use usbib?
I thought last time we diagnosed this, it was working fine until such a time that you had a connection failure?

ondrejmirtes · 2024-03-02T14:47:18Z

Alright, so the cable is JA-82T and not JA-80T, I researched that JA-80T is "usb to serial" and JA-82T is "usb HID", whatever that means. But it shows up a little bit differently in the system, under /dev/hidraw0.

I researched that instead of "ser2net" I need to use "usbip" which is the equivalent functionality, but for USB devices, not serial devices.

I've set up the cable with sudo usbip bind --busid='1-1.1.2' on the Raspberry and with sudo usbip attach --remote=192.168.0.32 --busid=1-1.1.2 on Ubuntu where HA runs.

I've set up the integration again, this time selecting JA-82T. It loaded the number and device details fine, and it started behaving exactly the same.

The behaviour I've described here #163 (comment) is what I'm seeing most of the time when I'm observing the behaviour.

Last weekend when I saw that it also noticed one window closed immediately (before the connection closed) was something I haven't seen before nor after. The behaviour in the linked comment is much more common.

ondrejmirtes · 2024-03-02T15:53:29Z

I have a couple of theories that would fit what I'm experiencing here:

The integration by accident changed some secret setting of the control panel that changes how the control panel communicates over serial. Unlikely, I know, and impossible to figure out how to revert it.
The behaviour of the control panel/serial communication is different and depends on the state of the system when the communication is initiated. E.g. There's going to be something different about the communication when initially there are no open windows vs. when there's at least one.

Number 2) would explain why it worked for me for a few weeks before breaking and also it'd explain why it worked for me last weekend for a few minutes.

ondrejmirtes · 2024-03-02T16:22:08Z

So my observation is that as long as there's no active sensors or only a single one, the system works fine, can detect window opening and closing immediately. But when I open multiple windows, the buggy behaviour steps in.

mattsaxon · 2024-03-02T16:38:38Z

That seems completely plausible. I have no door/window sensors to prove this.

Is this behaviour not stable and reproducible.

Can i suggest you document the recreation and put an info trace of the issue noting what times the system entered the various states, then this will be much easier to diagnose in the code. Can I suggest you ensure the time is synced before you do this

ondrejmirtes · 2024-03-02T17:47:57Z

Alright, here are some logs.

No windows opened initially, I opened a window around 18:31:15 and closed it 15 seconds later: https://gist.github.com/ondrejmirtes/5891445fa66a8135e55e4df29935bae1 - you can search for "message changed" and it shows when exactly it happened - everything worked fine.
No windows opened initially. I opened first window around 18:36:45, I opened a second window around 18:37:00. These events were noticed immediately. Then 15 seconds later around 18:37:15 I closed the second window, which goes unnoticed by HA (meaning the entity state changed is not in the logbook). And then around 18:37:30 I closed the first window and HA noticed that both windows are now closed at the same moment: https://gist.github.com/ondrejmirtes/705583424b065b71eb01147614f8591e - so it looks like having everything closed allows the system to "catch up" with the real state of the alarm, meaning it knows everything is closed.

In the 1st log there's only two lines saying something about Keypad beep, but in the 2nd log there's a lot more of these messages.

Also a lot of similar messages like this, which correspond to what we can see on the keypad: "2024-03-02 18:37:02.990 INFO (MainThread) [custom_components.jablotron80] JablotronStatusText(3): message changed from Triggered detector, 21:serial 01667955 to Triggered detector, 24:serial 01666124"

ondrejmirtes · 2024-03-22T12:25:55Z

I'm sorry to be that guy, but did you have a chance to look into this? Is there anything suspicious in my logs about the behaviour of the control panel? I'd be happy to pay you for your time.

Thank you.

mattsaxon · 2024-03-22T18:08:53Z

Sorry I havent had a chance to have a look.

It would be a lot easier for me to compare if you can weed out the verbose logging, which is too detailed for the issue we are having.

I will get round to this at some point, as I want to get on latest version too, what version are you on, please remind me.

Your recreation scenario is good so I can perhaps see if mine behaves the same way, I'm not sure I've ever tested with 2 open as I don't have a setup where this is likely, I don't have door/window sensors installed.

ondrejmirtes · 2024-03-22T18:31:20Z

What lines in logs in my last comment you want me to get rid of? #163 (comment)

It has raw data because I think that's what you need, right? I did these logs with verbose connection logging off I think.

I'm on the latest version, but I'm flexible in my setup and can try older versions (but I don't think updating them was the reason for these problems).

mattsaxon · 2024-03-22T18:34:25Z

I don't see a need for verbose logging at this stage. Actually First thing is I will see if I can recreate this somehow, then if I can I don't need any logs to be fair.

So let me have a think about how I might be able to reproduce with my setup.

Just not a priority for me right now, but I will get it it as some point

ondrejmirtes · 2024-03-22T18:43:30Z

My theory is that something is different about my control panel setup and the data you're gonna see when doing the same things are going to be different than what the integration expects.

So just comparing the expected data structure with my actual transferred data should be sufficient to say what's the different and how can we maybe adjust the integration so that it does not misbehave.

mattsaxon · 2024-03-22T18:45:32Z

Your theory may easily be right, but harder route of diagnosis! I'm being lazy, hoping for easy answer with easy test.

Even if I'm wrong I need to test it first

mattsaxon · 2024-03-29T10:44:30Z

OK, I've recreated this with a detector triggered at the same time as a faulty device (with version 0.32).
It loops between the 2 status on the dashboard.... not always, but sometimes.
However despite this unfortunate behaviour there are no further problems, so I agree this is a bug , but not necessarily that it is causing your stability issues.

Just about to upgrade to 0.34 (latest) to see if the behaviour is consistent, so then at least we are on same versions.

mattsaxon · 2024-03-29T10:45:50Z

Yes, same behaviour on 0.34!

ondrejmirtes · 2024-03-29T11:05:26Z

So the issue in my case is that the keypad is unusable because the integration cycles through all active detectors and doesn't let me press any button. And also that the integration does not notice a window closing immediately. And it doesn't let me disarm the alarm from HA when this is happening.

I think the root cause is that the code always executes the detail == 0x00 branch described here #163 (comment) which means the details are not in the payload at the position the integration expects it to. Maybe they are at a different position where it should be read from instead? Don't know :)

Do you see a way out of this problem? How #156 is going to help?

Anyway, I really appreciate your work! If you open GitHub Sponsors on your account, or tell me a way how to send some money your way, like PayPal, I'll make sure to send some appreciation your way :)

mattsaxon · 2024-03-29T11:25:23Z

156 may not help, but getting on a standard code base and tidying up the various pieces is a good foundation!

mattsaxon · 2024-03-30T10:38:49Z

Tested this morning again and whilst the physical keyboard is locked, I can disarm via HA, is that your experience? Can we separate out these various issues you are having as discrete issues? This original one is about the instability of your system, which I don't have issues.

Then you have identified this one with multiple is detectors, which seems similar conceptually at least to #156.

Then there is the one about not noticing something is closing independently too.

Can I ask you to open a separate issue for each and we can look at them independently.

mattsaxon · 2024-03-30T10:39:33Z

Closed on basis that stability issue not in the title are a local system phenomenon, not related to this code.

mattsaxon · 2024-03-30T10:47:17Z

Also check if #153 is what you are experiencing, I'm just testing this update at the moment, can you also test with it to see if it helps?

ondrejmirtes · 2024-03-30T13:44:19Z

Thanks, I'm testing it right now and gonna report back at the PR, and gonna open new issues for the persisting problems.

mattsaxon mentioned this issue Mar 29, 2024

fix #153 and fix #154 #156

Merged

mattsaxon closed this as completed Mar 30, 2024

This was referenced Mar 30, 2024

Wireless keypad spammed when multiple wireless sensors are active #167

Open

Not able to arm/disarm alarm reliably when multiple wireless sensors are active #168

Open

Weird behaviour after network update #163

Weird behaviour after network update #163

Comments

ondrejmirtes commented Feb 8, 2024

mattsaxon commented Feb 8, 2024

ondrejmirtes commented Feb 8, 2024

mattsaxon commented Feb 8, 2024

ondrejmirtes commented Feb 8, 2024

mattsaxon commented Feb 8, 2024

ondrejmirtes commented Feb 9, 2024

ondrejmirtes commented Feb 10, 2024

mattsaxon commented Feb 10, 2024

ondrejmirtes commented Feb 10, 2024

mattsaxon commented Feb 10, 2024

ondrejmirtes commented Feb 10, 2024

mattsaxon commented Feb 10, 2024

ondrejmirtes commented Feb 10, 2024

ondrejmirtes commented Feb 20, 2024

ondrejmirtes commented Feb 20, 2024

ondrejmirtes commented Feb 21, 2024

mattsaxon commented Feb 21, 2024

ondrejmirtes commented Feb 21, 2024

ondrejmirtes commented Feb 21, 2024

mattsaxon commented Feb 21, 2024

ondrejmirtes commented Feb 21, 2024

mattsaxon commented Feb 21, 2024

ondrejmirtes commented Feb 21, 2024

mattsaxon commented Feb 21, 2024

ondrejmirtes commented Feb 21, 2024

ondrejmirtes commented Feb 22, 2024

ondrejmirtes commented Feb 22, 2024

mattsaxon commented Feb 22, 2024

ondrejmirtes commented Feb 24, 2024

mattsaxon commented Feb 24, 2024

mattsaxon commented Feb 25, 2024 • edited Loading

ondrejmirtes commented Feb 25, 2024

mattsaxon commented Feb 25, 2024

ondrejmirtes commented Feb 25, 2024

mattsaxon commented Feb 25, 2024

ondrejmirtes commented Mar 2, 2024

mattsaxon commented Mar 2, 2024

ondrejmirtes commented Mar 2, 2024

ondrejmirtes commented Mar 2, 2024

ondrejmirtes commented Mar 2, 2024

mattsaxon commented Mar 2, 2024

ondrejmirtes commented Mar 2, 2024

ondrejmirtes commented Mar 22, 2024

mattsaxon commented Mar 22, 2024

ondrejmirtes commented Mar 22, 2024

mattsaxon commented Mar 22, 2024

ondrejmirtes commented Mar 22, 2024

mattsaxon commented Mar 22, 2024

mattsaxon commented Mar 29, 2024

mattsaxon commented Mar 29, 2024

ondrejmirtes commented Mar 29, 2024

mattsaxon commented Mar 29, 2024

mattsaxon commented Mar 30, 2024

mattsaxon commented Mar 30, 2024

mattsaxon commented Mar 30, 2024

ondrejmirtes commented Mar 30, 2024

mattsaxon commented Feb 25, 2024 •

edited

Loading