@OzGav Mine is v7.4 - no echo when I telnet to it (well the USR-TCP232) and enter “commands”.
Wow thanks, is that publicly available from ness? Or did you have to contact them?
I’ve been working off a very old revision (rev 5) that is missing a handful of details / has incorrect documentation that appears to have been fixed in that revision (judging by the changelog).
I have created a patch to add the carriage return/newline to each outgoing message, which should hopefully resolve this issue for you. Tested the patch on my panel and it didn’t seem to have any issues. (After all, the protocol specifies that you need to send a \r\n anyway)
FINISH. This is always CR, LF (Carriage Return, Line Feed).
@nickw444 , rev 5 is what is linked on Ness’ website. I got this rev some time ago from a guy of Austech forums, who I think was the guy that wrote it. I have requested the latest version, if its newer than 11 I’ll upload it.
Matt
1 Like
I submitted a support request with Ness and I got a reply. Version 13 is the latest. The reply is below:
Hello Anthony,
Thank you for the email received…
Information required is as follows:
The ASCII protocol is not published on the IP232 page.
Latest revision updated this week is REV13.
It is found on the Security Downloads page here
http://nesscorporation.com/index.php/webforms/index/index/id/45/
Direct link to file
http://www.nesscorporation.com/Software/Ness_D8-D16_ASCII_protocol_rev13.pdf
1 Like
Was about to upload the latest rev 13 but you beat me to it.
Anyways I updated to the latest HA beta (0.89.0b1) which should contain the latest Ness stuff. and it still crashes after a minute or so with this.
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File “/usr/local/lib/python3.7/site-packages/nessclient/client.py”, line 148, in keepalive
self._update_loop(),
File “/usr/local/lib/python3.7/site-packages/nessclient/client.py”, line 131, in _recv_loop
self.alarm.handle_event(event)
File “/usr/local/lib/python3.7/site-packages/nessclient/alarm.py”, line 50, in handle_event
self._handle_system_status_event(event)
File “/usr/local/lib/python3.7/site-packages/nessclient/alarm.py”, line 81, in _handle_system_status_event
return self._update_zone(event.zone, True)
File “/usr/local/lib/python3.7/site-packages/nessclient/alarm.py”, line 113, in _update_zone
zone = self.zones[zone_id - 1]
IndexError: list index out of range
Which was this response from the panel
8704036100110019030216301686
Cheers
I’m pretty sure I raised this with nick and he resolved it with a newer version of nessclient. It’s to do with a zone higher than number 9. https://github.com/nickw444/nessclient/issues/28
EDIT: I’m fairly certain it’s that as the event is that zone 11 is entering the unsealed state.
The current version of the home assistant module references 0.9.13 which doesn’t have the update. It needs to reference 0.9.14
@nickw444, can you please update the hass module to use ness client 0.9.14?
I’m getting the following error a couple of times. Anybody else seeing this?
2019-03-05 07:54:57 WARNING (MainThread) [nessclient.client] Failed to decode data
Traceback (most recent call last):
File “/config/deps/lib/python3.7/site-packages/nessclient/client.py”, line 114, in _recv_loop
decoded_data = data.decode(‘utf-8’).strip()
UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0x9a in position 28: invalid start byte
I’ll try find some time to raise the PR against Home-Assistant tomorrow. Remember, anyone can do this, it’s just a two line change: Bump nessclient version to 0.9.13 by nickw444 · Pull Request #21466 · home-assistant/core · GitHub
@OzGav can you provide some debug log lines before the exception was logged? Would be good to show the raw data as it was received so I can see what was being decoded exactly.
Thanks Nick. I’ll get back to you.
Thanks Nick!
@nickw444 Happened to notice you had submitted a PR with the inclusion of a configurable scan_interval, so I fired up a quick HA dev branch container to try it out.
It works wonderfully, thank you for the component and this latest inclusion for those of us who have older panels! 
I’ve set mine at 2 seconds which is nice and responsive. However, by having it update that frequently (not knowing the ins and outs of HA) is there any downside?
There shouldn’t be any major downside to doing this, after all there are many other polling type components in home assistant. The only issue you may see is elevated CPU usage, but calling update at this rate should be negligible - it’s a very lightweight call.
I have added some code to printout the undecoded data so this is what I see a couple of times. Not sure if it will be much help? The colons are part of my code just so I could see if there any spaces that I couldnt see. So the returned data is what is between the colons. And this is from two days of records from every minute so not many failures… Also bear in mind because of the echo I am seeing I am taking the last 28 characters of decoded_data but the line “Failed to decode data” is using this code:
_LOGGER.warning(“Failed to decode data :%s:”, data)
2019-03-07 08:29:09 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-07 08:29:09 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S00E9\r\n’
2019-03-07 08:29:09 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S14E4\r\n’
2019-03-07 08:29:09 WARNING (MainThread) [nessclient.client] Failed to decode data :b’870003610005001903\x00!\x00\x08 \x00\x00\x08\x00\x02\xe1’:
2019-03-07 08:29:09 DEBUG (MainThread) [nessclient.client] Decoding data: ‘8300360S14E4’
2019-03-07 08:29:09 INFO (MainThread) [nessclient.client] Skipping Packet 8300360S14E4
2019-03-07 12:08:35 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-07 12:08:35 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S00E9\r\n’
2019-03-07 12:08:35 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S14E4\r\n’
2019-03-07 12:08:35 WARNING (MainThread) [nessclient.client] Failed to decode data :b’8700036101060019030712045085\x05\x00\x82\x82\x9a\xb2\x82\x9a\xc10E9’:
2019-03-07 12:08:35 DEBUG (MainThread) [nessclient.client] Decoding data: ‘8300360S14E4’
2019-03-07 12:08:35 INFO (MainThread) [nessclient.client] Skipping Packet 8300360S14E4
019-03-07 13:56:41 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-07 13:56:41 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S00E9\r\n’
2019-03-07 13:56:41 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S14E4\r\n’
2019-03-07 13:56:41 WARNING (MainThread) [nessclient.client] Failed to decode data :b’870083610006\x00 \x01\t \x01\x00!\x00\x01\x08\xa4\t\x08 \x02\x82\x9a\xb2\x82\x9a\xc54E4’:
2019-03-07 16:20:45 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-07 16:20:45 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S00E9\r\n’
2019-03-07 16:20:45 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S14E4\r\n’
2019-03-07 16:20:45 DEBUG (MainThread) [nessclient.client] Decoding data: ‘8700036101060019004 !)B’
2019-03-07 16:20:45 DEBUG (MainThread) [nessclient.packet] Decoding bytes: ‘00036101060019004 !)B’
2019-03-07 16:20:45 ERROR (MainThread) [nessclient.client] Failed to decode packet :00036101060019004 !)B:
2019-03-07 16:20:45 DEBUG (MainThread) [nessclient.client] Decoding data: ‘8300360S14E4’
2019-03-07 16:20:45 INFO (MainThread) [nessclient.client] Skipping Packet 8300360S14E4
2019-03-07 21:11:17 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-07 21:11:17 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S00E9\r\n’
2019-03-07 21:11:17 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S14E4\r\n’
2019-03-07 21:11:17 DEBUG (MainThread) [nessclient.client] Decoding data: ‘0$D’
2019-03-07 21:11:17 DEBUG (MainThread) [nessclient.packet] Decoding bytes: ‘0$D’
2019-03-07 21:11:17 ERROR (MainThread) [nessclient.client] Failed to decode packet :0$D:
2019-03-07 21:11:17 DEBUG (MainThread) [nessclient.client] Decoding data: ‘20’
2019-03-07 21:11:17 DEBUG (MainThread) [nessclient.packet] Decoding bytes: ‘20’
2019-03-07 21:11:17 ERROR (MainThread) [nessclient.client] Failed to decode packet :20:
2019-03-07 21:11:17 DEBUG (MainThread) [nessclient.client] Decoding data: ‘’
2019-03-07 21:11:17 INFO (MainThread) [nessclient.client] Skipping Packet
2019-03-08 01:21:29 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-08 01:21:29 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S00E9\r\n’
2019-03-08 01:21:29 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S14E4\r\n’
2019-03-08 01:21:29 DEBUG (MainThread) [nessclient.client] Decoding data: ‘8700036101060019030801174290’
2019-03-08 01:21:29 DEBUG (MainThread) [nessclient.packet] Decoding bytes: ‘8700036101060019030801174290’
2019-03-08 01:21:29 WARNING (MainThread) [nessclient.client] Failed to decode data :b’\x9a\x82\x82\x9a\xb2\x82\x9a\xc10E9’:
2019-03-08 01:21:29 DEBUG (MainThread) [nessclient.client] Decoding data: ‘8300360S14E4’
2019-03-08 01:21:29 INFO (MainThread) [nessclient.client] Skipping Packet 8300360S14E4
2019-03-08 06:06:44 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-08 06:06:44 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S00E9\r\n’
2019-03-08 06:06:44 DEBUG (MainThread) [nessclient.client] Sending payload: ‘8300360S14E4\r\n’
2019-03-08 06:06:44 WARNING (MainThread) [nessclient.client] Failed to decode data :b’870003610106001903080602578B\x08\x02\x82\x9a\xb2\x82\x9a\xc10E9’:
2019-03-08 06:06:44 DEBUG (MainThread) [nessclient.client] Decoding data: ‘8300360S14E4’
2019-03-08 06:06:44 INFO (MainThread) [nessclient.client] Skipping Packet 8300360S14E4
Currently 4 days uptime since 0.89 update hopefully continues
@nickw444 Since upgrading to 0.89.1 running nessclient==0.9.13 after a few seconds of the alarm entering the armed state it reverts to disarmed even though the system is still armed. I’ve tried running nessclient==0.9.14 with no improvement.
I’m also not seeing any errors in the log that would be beneficial. I’ve gone back and fourth to double check the difference in logged output from nessclient.
0.88.2
State Update
2019-03-12 01:47:22 DEBUG (MainThread) [nessclient.client] Forcing a keepalive state update
2019-03-12 01:47:22 DEBUG (MainThread) [nessclient.client] Decoding data: '820003600000001b'
2019-03-12 01:47:22 DEBUG (MainThread) [nessclient.packet] Decoding bytes: '820003600000001b'
0.89.1
State Update
2019-03-12 01:53:04 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-12 01:53:04 DEBUG (MainThread) [nessclient.client] Sending payload: '8300360S00E9\r\n'
2019-03-12 01:53:04 DEBUG (MainThread) [nessclient.client] Sending payload: '8300360S14E4\r\n'
I’ve observed that when the new state update fires in 0.89.1 with nessclient==0.9.13 it causes the alarm to reset it’s state to disarmed
I dont believe these are the same thing. The first is the section of code that executes when a string is received from the panel. The second is the component sending a message to the panel.
Mine is rock-solid too. Is it only people with “earlier” panel versions (e.g <=v7) having issues, like @cryptelli?
Can I check panel version from keypad?
Agreed. They’re different but point I was trying to make was in an 0.88.2 environment the a state update wouldn’t automatically trigger the Sending payload: part, now it does.
Full version
2019-03-12 01:53:04 DEBUG (MainThread) [nessclient.client] Requesting state update from server (S00, S14)
2019-03-12 01:53:04 DEBUG (MainThread) [nessclient.client] Sending payload: '8300360S00E9\r\n'
2019-03-12 01:53:04 DEBUG (MainThread) [nessclient.client] Sending payload: '8300360S14E4\r\n'
2019-03-12 01:53:05 DEBUG (MainThread) [nessclient.client] Decoding data: '820003600000001b'
2019-03-12 01:53:05 DEBUG (MainThread) [nessclient.packet] Decoding bytes: '820003600000001b'
2019-03-12 01:53:06 DEBUG (MainThread) [nessclient.client] Decoding data: '8200036014000007'
2019-03-12 01:53:06 DEBUG (MainThread) [nessclient.packet] Decoding bytes: '8200036014000007'
I fear it might be… whatever changes were made for the newer revisions might have adversely me due to the reason stated.
Having same problem you’re having. Haven’t read logs yet but last night went to set armed home and it reverts back to disarm after a few arming flashes. Check with Ness app and it is armed.
If I arm via keypad then it updates status correctly.