Ness DX8/DX16 Alarm

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 …

@FrontBottom oh well there goes that idea then :slight_smile:

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?

@OzGav Id suggest trying it as per the Austech forums posts.

Matt

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:

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.