That is odd. My notifications are pretty instantaneous - I can walk around with an HA client and the HA sensors show motion less than 1 sec after my NESS PIR’s show motion (via red LED)
So just to be clear - you get the same:
2019-01-30 18:47:14 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved ...
type message, where the keepalive polling seems to crap itself?
Are you using the “genuine” IP232? I wonder if it is just @nickw444 and myself using non-genuine? It would be nice to be able to get SYSLOG or similar off the converters - but if the IP232 is anything like the USR one, it doesn’t have any logging capability
Can you guys also confirm that even straight after a reboot (with debugging on that Nick mentioned), you don’t see message like this (which correspond to the Zone event notification from the NESS):
Might be worth also confirming what you have set in P199E? (I assume you guys have done the config required on the NESS side in order to get it to spit out ASCII on the serial port??)
I have a non genuine converter, also P199E are all enabled. My nessclient seems to work fine on initial boot but at some point within the first few minutes it crashes on decoding a zone change. Thought it might have been the same zone, but with the three captures I’ve grabbed it’s three different zones have caused it.
As I have my own software also monitoring the port I can grab the exact packet it fails on.
Thanks for all the debug information, this will be quite helpful for when I get a moment to take a look into the issue further (hopefully this coming weekend).
Please continue to post any additional findings or suspicious logs you may come across, as this will help me narrow down the problem.
@FrontBottom that is how I’d imagine the system would work, jealous that yours is running that well haha!
I’ve seen that error, but am finding this error more common:
2019-02-04 16:30:41 DEBUG (MainThread) [nessclient.client] Forcing a keepalive state update
2019-02-04 16:30:41 DEBUG (MainThread) [nessclient.client] Decoding data: '820003600001001a'
2019-02-04 16:30:41 DEBUG (MainThread) [nessclient.packet] Decoding bytes: '820003600001001a'
2019-02-04 16:30:51 DEBUG (MainThread) [nessclient.client] Decoding data: '820361230001f6'
2019-02-04 16:30:51 DEBUG (MainThread) [nessclient.packet] Decoding bytes: '820361230001f6'
2019-02-04 16:31:41 DEBUG (MainThread) [nessclient.client] Forcing a keepalive state update
2019-02-04 16:32:41 DEBUG (MainThread) [nessclient.client] Forcing a keepalive state update
2019-02-04 16:32:41 DEBUG (MainThread) [nessclient.client] Closing stale connection and reconnecting
2019-02-04 16:32:41 DEBUG (MainThread) [nessclient.client] Attempting to connect
The above continues, never decoding any further packets until HA is restarted.
Yes. I’m using the geniune Ness ELK-IP232.
I receive the message right after a reboot.
I’ll confirm what settings were programmed when the unit was installed.
I’ve noticed that upon arming my system through HA that it triggers a loss of connection in the logs of HA and if running ness-cli at the same time receive the following:
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED
ValueError: 39 is not a valid CommandType
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/bin/ness-cli", line 10, in <module>
sys.exit(cli())
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 764, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 1137, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.7/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/nessclient/cli/events.py", line 30, in events
client.update(),
File "/usr/lib/python3.7/asyncio/base_events.py", line 584, in run_until_complete
return future.result()
File "/usr/local/lib/python3.7/dist-packages/nessclient/client.py", line 141, in keepalive
self._update_loop(),
File "/usr/local/lib/python3.7/dist-packages/nessclient/client.py", line 118, in _recv_loop
pkt = Packet.decode(decoded_data)
File "/usr/local/lib/python3.7/dist-packages/nessclient/packet.py", line 116, in decode
command = CommandType(data.take_hex())
File "/usr/lib/python3.7/enum.py", line 309, in __call__
return cls.__new__(cls, value)
File "/usr/lib/python3.7/enum.py", line 561, in __new__
raise exc
File "/usr/lib/python3.7/enum.py", line 545, in __new__
result = cls._missing_(value)
File "/usr/lib/python3.7/enum.py", line 574, in _missing_
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 39 is not a valid CommandType
That’s good news on the general stability. Looks like the library might be expecting the full ASCII string. With the alarm status - do you have an alarm_panel configured? I think until I set the alarm from the card, it didn’t seem to represent the state correctly …??
Not that it helps anyone else - but mine continues to be rock solid …
You’re correct, since enabling all P199E options the alarm state is now working quite well (alarm_panel has been configured from the get go). But the sensors are still too slow when compared to the PIR in one of my sensor nodes which responds almost instantly for triggered and clear.
@aumatt before posting that I thought twice as I wasn’t sure exactly what you meant. I’m assuming the the location of the panel version is a sticker on the main chip which is labelled “V5.7”?
Do I need to do any further config that that? When I arm I check the state of alarm_control_panel.alarm_panel and it stays disarmed although it has armed on the ness.
I also have the issue of movement sensors not changing in HA unless I sit there and wave my arms around for a good 20 seconds, then it will finally change state. As mentioned by someone else, it seems that you need to trigger the sensor when it is being polled to have it reflect in HA.
