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.