Ness DX8/DX16 Alarm

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.

Hmmm… Thought it would https://developers.home-assistant.io/docs/en/creating_component_loading.html

I am using some other custom components and all of those have either a setup or setup_platform function but yours doesn’t and thus I am getting this error:

019-02-21 11:51:24 ERROR (MainThread) [homeassistant.setup] Error during setup of component ness_alarm
Traceback (most recent call last):
File “/usr/local/lib/python3.6/site-packages/homeassistant/setup.py”, line 148, in _async_setup_component
component.setup, hass, processed_config) # type: ignore
AttributeError: module ‘custom_components.ness_alarm’ has no attribute ‘setup’

So I might have to wait until you roll that into an update because I don’t think I can install anything outside of the config directory. This is unfortunate because I was hoping to be able to easily modify the code to solve the problem I am having with multiple messages being returned all joined together.

@nickw444 Thank you for your continued support of the Ness component. I’ve updated to 0.9.10 even though I’ve been quite stable any improvements are welcome.

I’m more concerned with the lack of responsiveness in the sensors detecting motion and the state in HA changing. Do you think you could look into this next? I’m currently only using the component to arm/disarm the alarm due to the sensor delays.

Interesting. You are using the Ness IP232 and don’t have this run together message problem but arent getting the responses quickly. I get an instant response to a zone tripping but it comes back with a long message which crashes the routine. I feel this is solvable!

BTW are you running on a Raspberry PI? If so how did you update?

I agree!

It’s been suggested before that the delay seems to be caused due to it only sending zone states when it polls, would be interested to hear @nickw444 thoughts on this.

Regarding your question I’m running HA in a python virtual environment, so while active in the environment just issued pip3 install --upgrade nessclient

Sorry if we have already covered this off - @cryptelli; when you have debug logging on as suggested by Nick, do you see messages coming from your NESS? If not, it might be worth connecting directly to NESS serial port (e.g via putty) and confirming if you get messages on zone changes?

@FrontBottom Yep, am receiving decode messages, they’re just too delayed.

If you are seeing messages delayed when connected via putty then that sounds to me like there is an issue with the IP232