Ness DX8/DX16 Alarm

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

I meant via HA, haven’t as yet connected directly to the IP232.

I think you may be confused, the nessclient library is the underlying library that the ness_alarm HA component is using. There is no need to put anything into your custom_components directory, but rather you just need to upgrade the dependency being used. As @cryptelli mentioned, this can be done using pip.

With this being said, I raised a pull request to home-assistant core to have the version being used upgraded, so this should make it into 0.89.0 in 1.5 weeks. (From personal testing, this update appears to solve the dropouts)

This one might be a bit harder to look into than expected - For myself, I don’t have this issue, regardless of whether I use the Ness IP232 module or my “aftermarket” one. As @FrontBottom mentioned, I think it’s going to be easiest to debug this if you can use telnet or netcat (nc) to look at the raw output from the alarm to determine where the delay is - whether it’s in home-assistant, nessclient library, an IP/connectivity issue, or whether the alarm panel is outputting messages delayed (or not at all). I know that there is an option in the P199E settings to turn off/on zone update outputs - this needs to be turned on in order to receive real-time updates, otherwise it is only polled on a once-per-minute basis.

Should have done it sooner really… the delay isn’t coming from your component or HA. Though your post has been quite enlightening and believe the answer may be in last line of your comment.

The P199E settings, in particular option 6 as explained in the manual relates to Send Zone Seal State with the disclaimer of (D8x/D16x V6 and later.). As I’m running v5.7 was concerned this might be part of it however it still sends updates just not frequently.

Then you mention:

This is what’s happening… It usually takes a minute before a zone is triggered but often reverts in a couple of seconds.

So… is there an easy way to fix this like a firmware update or am I screwed?

New board? https://www.ebay.com.au/itm/NESS-110-770-D8X-PCB-BOARD/123643727560

Doesn’t look good for a firmware update :frowning: https://www.austech.info/showthread.php/100429-Ness-D8X-Firmware-update-is-it-possible

As far as I can tell pip doesn’t work with hassio.What does happen though is the dependency is installed by hassio on first run in the following path:

\hassio\config\deps\lib\python3.6\site-packages

So I could go in there and after it was updated to 0.9.10 (which occurred because I added your latest version of ness_alarm to custom components) I added the line I mentioned earlier to client.py

if len(decoded_data) > 28: decoded_data = decoded_data[-28:]

This has solved my particular problem where I was getting multiple packets joined together and it appears to be working perfectly. I will update you when I have a chance to test it more tomorrow.

I think a workaround for this would be for me to make the polling interval configurable - such that you can set a config option for the ness_alarm component to poll at an interval of 5 seconds (or faster if you felt the need). I’ll try make this change to get it into the next release of HA.

Ah fun, I’m not very familiar with hassio as I run my HA in docker on a home server (rather than a Pi).

With this issue of having multiple packets joined together - I’m curious as to whether it’s due to a configuration option in your IP232 dongle. Do you think you can post a screenshot of the settings you’re using. IIRC you’re using the genuine ness one, right?

Of course I can implement the “fix”, but I’d rather avoid it as it may introduce other problems - i.e. your fix here simply trims the subsequent messages, which may be important, and only works for P199E (all options) messages (timestamps, address).

I am using a USR-TCP232-302 Here is the config https://ibb.co/NmJMG2r

You are right about the “fix”. I can just keep making the change at my end. I assume this message 8300360S00E9 is HASSIO sending the keep alive message. The response is joined onto that message for me. The other thing I thought of that shouldn’t break anything is for that message to be sent with a CR on the end of it. That might break apart the messages. I haven’t had time to look at where you are constructing the string to send to add that on…

Excellent, that sounds like a plausible solution. I’d be happier with anything quicker than what I have currently :+1:.

Thanks again Nick.

Thanks for all your effort Nick, I’ll test it out in the next release. I have also discovered a bug in my D16X panel where if a zone is in a unsealed state for around 10min it reports the zone as sealed. Initially I thought my program was failing but on further logging I discovered that the panel itself is sending a sealed status back for that input even though the panel still declares the zone as unsealed. I’ve only tested on one input at the moment but am going to test another input today.

Matt

Interesting, I have the same module but don’t have the same issue. Maybe it’s something like an echo reply settings. The only difference I can see in mine is that I have RESET checkbox turned off.

For reference this is my “Expand Function” page, perhaps yours is slightly different config too?

49%20am

Hope that helps.

I found an interesting bug last night that caused my state updates to stop working - there is a bug in the panel that causes state & event updates sent exactly on the hour to send an “invalid time” - i.e. 17:60:00 :man_shrugging: I have released a fix for this, so hopefully will land in the next HA release too.

Nick, TBH I think the serial in general is very flaky going by what I am seeing. I havent seen the 60th minute bug on my panel and I have been monitoring my alarm for I’d say 4 years. So maybe different firmware. What version do you get when you issue a Status 17? That should return the Panel Software Version.

Nice find. I have tried my other fix and added to line 71 of packet.py

    data += '\r\n'

This has broken apart the messages but just for some reason I am seeing the keep alive message echoed back to HASSIO so that this happens:

019-02-26 13:10:12 WARNING (MainThread) [nessclient.client] Failed to decode packet
Traceback (most recent call last):
File “/config/deps/lib/python3.6/site-packages/nessclient/client.py”, line 121, in _recv_loop
event = BaseEvent.decode(pkt)
File “/config/deps/lib/python3.6/site-packages/nessclient/event.py”, line 39, in decode
return StatusUpdate.decode(packet)
File “/config/deps/lib/python3.6/site-packages/nessclient/event.py”, line 147, in decode
request_id = StatusUpdate.RequestID(int(packet.data[0:2], 16))
ValueError: invalid literal for int() with base 16: ‘S0’

Your update means the component keeps soldiering on which is great but it is odd. My “expand function” page is the same as yours. Is my firmware version the same as yours?

The only other thing I am seeing is an unsealed state even when there is no movement but I think this might be a dodgy PIR so I will try and replace it.

Again thanks Nick for putting this together it is a great addition to Home Assistant.