All good - worked it out
Thanks for reporting similar behaviour, at the moment it seems the responsiveness seems mixed upon the feedback received from different people. @FrontBottom to my knowledge is the only one who isnāt experiencing any issues.
perhaps a different firmware version?
Quite possibly. @FrontBottom could you please let us know what your panel version is with the command below?
Ahh I think I see the issue, in version 6 NESS added an addtional option on the Serial Port Output. ā6E ON: Send Zone Seal State. (D8x/D16x V6 and later.)ā . Which I have enabled as I use that for my software. Iāll disable it and see whether that fixes the crashing.
My panel is a v7.0 panel.
Matt
I set mine to ON as it was off then I started getting correct zone updates but after 2 hrs everything timed out again and would only work after HA restart. Least I have the sensors working.
Got my arm/unarm working so my only issue is the sensor updates. Not sure about whether it is dropping off but havenāt noticed anything - but havenāt used it much yet. Will let you all know.
v7.4 for me.
And @aumatt - regarding Zone Seal State (P199E 6E) - I definitely have that (and all other P199E options) enabled ā¦
Hereās my logs right before it stops decoding.
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/nessclient/client.py", line 141, in keepalive
self._update_loop(),
File "/usr/local/lib/python3.6/site-packages/nessclient/client.py", line 119, in _recv_loop
event = BaseEvent.decode(pkt)
File "/usr/local/lib/python3.6/site-packages/nessclient/event.py", line 39, in decode
return StatusUpdate.decode(packet)
File "/usr/local/lib/python3.6/site-packages/nessclient/event.py", line 147, in decode
request_id = StatusUpdate.RequestID(int(packet.data[0:2], 16))
File "/usr/local/lib/python3.6/enum.py", line 291, in __call__
return cls.__new__(cls, value)
File "/usr/local/lib/python3.6/enum.py", line 533, in __new__
return cls._missing_(value)
File "/usr/local/lib/python3.6/enum.py", line 546, in _missing_
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 23 is not a valid RequestID
Then itās the same three lines repeated.
2019-02-08 16:53:32 DEBUG (MainThread) [nessclient.client] Forcing a keepalive state update
2019-02-08 16:53:32 DEBUG (MainThread) [nessclient.client] Closing stale connection and reconnecting
2019-02-08 16:53:32 DEBUG (MainThread) [nessclient.client] Attempting to connect
I have got all the parts and have hooked mine up. HASS is showing connected to the module but when I telnet into it I only am seeing the following string output over and over again regardless of which zoine is tripped
8300360S00E9
Is this actually HASS asking for a status update? If so it doesnt appear I am seeing any info from the board?
Have you got all the P199E options enabled?
Yes I am wondering if my cable I bought isnāt wired up correctly. Looking at the Austech forum I see there were discussions about whether some of these serial cables werenāt correct. Can you confirm what each pin is starting from the side where the telephone jack is? Is it GND - TX - RX ? My plug isnāt wired like that?
Thanks Matt. I swapped all the wires around and that has it working.
However now I am getting a crash due to āUnable to consume all dataā due to this sequence ā8300360S14E48300360S00E98300360S00E987008361000600190216204117e6ā which looks like it is maybe an echo from HASSIO requesting three status updates and then a properly formed response.
Is anyone else seeing this? If not and if you are using a USR-TCP232-302 can you tell me what your settings are on the Serial Port page? I have tried setting LINK off and also āSimilar RFC2217ā but that didnt make any difference?
Edit: I wonder if the packet was sent with a CR on the end if that would help?
Hi @OzGav
Iāve got 9600,8,N,1 and then LINK and āSimilar RFC2217ā set on my USR-TCP232
A bit of a development on my side - I upgraded from ResinOS to HassOS this morning - along with an upgrade from 0.87 to 0.87.1 and I havenāt been able to get stable NESS since!
Some more digging to be done ā¦
I havent got time for a few days but I am thinking of adding to client.py the following on line 117
if len(decoded_data) > 28: decoded_data = decoded_data[-28:]
This would strip off the actual data I need from my spurious extra long data!
Hi all,
Sorry for the delay since I last posted. I found a small amount of time this morning and have raised a handful of pull requests to hopefully make the client library more stable:
- https://github.com/nickw444/nessclient/pull/23
- https://github.com/nickw444/nessclient/pull/22
- https://github.com/nickw444/nessclient/pull/21
I found that the documentation provided by Ness is inconsistent with regard to the endianness of the data returned for a few of the user interface responses. The fixes should improve the following:
- Initial state can be determined better when a restart of Hass occurs
- If a packet fails to be decoded, the listen loop should not crash.
I have released version 0.9.10
of the nessclient
library, perhaps a handful of you all here can give it a try and let me know how it goes. If successful, Iāll raise a PR in home-assistant to upgrade to this version
I can just copy 0.9.10 into a ness_alam directory that I create under custom components canāt I? That will override the current version?
I am unsure if that would work. I think you will need to pip install
it from within the home-assistant virtual environment (if one exists).
pip install --upgrade [email protected]
Might be a bit more complicated if you are running inside docker though.