Ness DX8/DX16 Alarm

FrontBottom · March 12, 2019, 1:15pm

The beauty, wonder and conundrum of HA - 25 differnt ways to achieve the same outcome. Most of them not elegant when I finish with them

cryptelli · March 12, 2019, 1:16pm

Yup, doesn’t have to be pretty to be functional!

aumatt · March 13, 2019, 3:44am

Im thinking im still on 0.9.13 as im on 0.89.1, any way to find out what version im running. Also anyway you can update nessclient from ssh in docker?
Matt

cryptelli · March 13, 2019, 5:39am

Try running pip3 show nessclient to verify what version you’re on. Then you can run pip3 install nessclient==0.9.14 to upgrade.

nickw444 · March 13, 2019, 10:44am

Interesting you mention this - the client will transition through different states when an arm occurs - should go via arming, exit_delay then armed. This appears to work as expected for me. Can you confirm this is the case for you? I noticed you mentioned some things about automations above.

Unfortunately this fix didn’t make it into the 0.89 release, but should make be in 0.90. As other mentioned, you can upgrade the client manually in the container.

cryptelli · March 13, 2019, 10:50am

I can only see mine go through arming and then disarmed, occasionally it will enter armed before quickly reverting to disarmed

I’ve triple checked that I don’t have any automation which could be interfering and disabled the one I do have (only sends push notifications upon alarm state changes). Problem doesn’t exist under 0.88.2 with same configuration.

Yuddy · March 13, 2019, 11:04am

I have no automations atm until I’m sure it’s all running well. I notice it will not update alarm status correctly if I do it via HA, but if I do it via Ness and keypad it works. “arming” only flashes for like 3-5 seconds then will go back to disarm then will goto armed away once system is actually armed after the cooldown beeps for leaving

nickw444 · March 13, 2019, 11:04am

Very weird, but I expect it is due to the changes I made in Get arming state on update by nickw444 · Pull Request #25 · nickw444/nessclient · GitHub.

To confirm, can you install the latest version of nessclient and run:

ness-cli events --host alarm.home --port 8234

And whilst that is listening, arm your panel manually and watch for messages like

Alarm state changed to ArmingState.DISARMED

Can you let me know the flow it goes through when you do this please?

nickw444 · March 13, 2019, 11:05am

For me, it does the following:

Alarm state changed to ArmingState.DISARMED
** send arm command **
Alarm state changed to ArmingState.ARMING
Alarm state changed to ArmingState.EXIT_DELAY
Alarm state changed to ArmingState.ARMED
** send disarm command **
Alarm state changed to ArmingState.DISARMED
...

And does not go back into DISARMED as far as I can tell

cryptelli · March 13, 2019, 11:14am

Ok. Updated to nessclient==0.9.14 and the results are below:

note no disarm command was sent

Alarm state changed to ArmingState.DISARMED
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 20, 1, 39, 14), 'type': <EventType.ARMED_NIGHT: 39>, 'zone': 1, 'area': 3}>
Alarm state changed to ArmingState.ARMING
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 20, 1, 39, 14), 'type': <EventType.EXIT_DELAY_START: 34>, 'zone': 1, 'area':
3}>
Alarm state changed to ArmingState.EXIT_DELAY
<ZoneUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ZONE_INPUT_UNSEALED: 0>, 'included_zones': []}>
Zone 1 changed to False
Zone 2 changed to False
Zone 3 changed to False
Zone 4 changed to False
Zone 5 changed to False
Zone 6 changed to False
Zone 7 changed to False
Zone 8 changed to False
Zone 9 changed to False
Zone 10 changed to False
Zone 11 changed to False
Zone 12 changed to False
Zone 13 changed to False
Zone 14 changed to False
Zone 15 changed to False
Zone 16 changed to False
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED

nickw444 · March 13, 2019, 11:16am

Very interesting, do you mind doing that again, except this time with debug enabled?

ness-cli --log-level debug events --host alarm.home --port 8234

Would like to get to the bottom of why your alarm is responding to the S14 request with a disarmed state.

cryptelli · March 13, 2019, 11:19am

Sure, anything I can do to help figure this thing out. Results from --log-level debug

DEBUG:nessclient.client:Attempting to connect
DEBUG:nessclient.client:Decoding data: '8200036014000007'
DEBUG:nessclient.packet:Decoding bytes: '8200036014000007'
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED
DEBUG:nessclient.client:Decoding data: '820003600000001b'
DEBUG:nessclient.packet:Decoding bytes: '820003600000001b'
<ZoneUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ZONE_INPUT_UNSEALED: 0>, 'included_zones': []}>
Zone 1 changed to False
Zone 2 changed to False
Zone 3 changed to False
Zone 4 changed to False
Zone 5 changed to False
Zone 6 changed to False
Zone 7 changed to False
Zone 8 changed to False
Zone 9 changed to False
Zone 10 changed to False
Zone 11 changed to False
Zone 12 changed to False
Zone 13 changed to False
Zone 14 changed to False
Zone 15 changed to False
Zone 16 changed to False
DEBUG:nessclient.client:Decoding data: '8700036127010318072001441353'
DEBUG:nessclient.packet:Decoding bytes: '8700036127010318072001441353'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 20, 1, 44, 13), 'type': <EventType.ARMED_NIGHT: 39>, 'zone': 1, 'area': 3}>
Alarm state changed to ArmingState.ARMING
DEBUG:nessclient.client:Decoding data: '87008361220103180720014413d8'
DEBUG:nessclient.packet:Decoding bytes: '87008361220103180720014413d8'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 20, 1, 44, 13), 'type': <EventType.EXIT_DELAY_START: 34>, 'zone': 1, 'area':
3}>
Alarm state changed to ArmingState.EXIT_DELAY
DEBUG:nessclient.client:Decoding data: '8700036123000318072001442249'
DEBUG:nessclient.packet:Decoding bytes: '8700036123000318072001442249'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 20, 1, 44, 22), 'type': <EventType.EXIT_DELAY_END: 35>, 'zone': 0, 'area': 3}>
Alarm state changed to ArmingState.ARMED
DEBUG:nessclient.client:Decoding data: '820003600000001b'
DEBUG:nessclient.packet:Decoding bytes: '820003600000001b'
<ZoneUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ZONE_INPUT_UNSEALED: 0>, 'included_zones': []}>
DEBUG:nessclient.client:Decoding data: '8200036014000007'
DEBUG:nessclient.packet:Decoding bytes: '8200036014000007'
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED

nickw444 · March 13, 2019, 11:25am

Looks like it might be due to the arming mode you’re using here, I have only tested with arm away, no other modes like arm home, etc. as we do not use these in my household.

Are you able to see if the issue persists if you try arm using arm away instead? (Ultimately we’d find a way to have this library support all arming modes, after all, the official app supports it)

cryptelli · March 13, 2019, 11:30am

We don’t usually either, just exclude a few zones and then arm_away but was thinking about using home in the future.

I believe arm_home wasn’t an issue before either, even though you hadn’t tested it.

Debugged again, this time using arm_away

DEBUG:nessclient.client:Attempting to connect
DEBUG:nessclient.client:Decoding data: '8200036014000007'
DEBUG:nessclient.packet:Decoding bytes: '8200036014000007'
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED
DEBUG:nessclient.client:Decoding data: '820003600000001b'
DEBUG:nessclient.packet:Decoding bytes: '820003600000001b'
<ZoneUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ZONE_INPUT_UNSEALED: 0>, 'included_zones': []}>
Zone 1 changed to False
Zone 2 changed to False
Zone 3 changed to False
Zone 4 changed to False
Zone 5 changed to False
Zone 6 changed to False
Zone 7 changed to False
Zone 8 changed to False
Zone 9 changed to False
Zone 10 changed to False
Zone 11 changed to False
Zone 12 changed to False
Zone 13 changed to False
Zone 14 changed to False
Zone 15 changed to False
Zone 16 changed to False
DEBUG:nessclient.client:Decoding data: '8700036124010118072001535804'
DEBUG:nessclient.packet:Decoding bytes: '8700036124010118072001535804'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 20, 1, 53, 58), 'type': <EventType.ARMED_AWAY: 36>, 'zone': 1, 'area': 1}>
Alarm state changed to ArmingState.ARMING
DEBUG:nessclient.client:Decoding data: '8700836122010118072001535886'
DEBUG:nessclient.packet:Decoding bytes: '8700836122010118072001535886'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 20, 1, 53, 58), 'type': <EventType.EXIT_DELAY_START: 34>, 'zone': 1, 'area':
1}>
Alarm state changed to ArmingState.EXIT_DELAY
DEBUG:nessclient.client:Decoding data: '8700036123000118072001540756'
DEBUG:nessclient.packet:Decoding bytes: '8700036123000118072001540756'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 20, 1, 54, 7), 'type': <EventType.EXIT_DELAY_END: 35>, 'zone': 0, 'area': 1}>Alarm state changed to ArmingState.ARMED
DEBUG:nessclient.client:Decoding data: '8200036014000007'
DEBUG:nessclient.packet:Decoding bytes: '8200036014000007'
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED

nickw444 · March 13, 2019, 9:34pm

Thanks for that extra info. Definitely looks like an issue with the way your panel responds to the Arming request that nessclient makes. However something is a bit suspicious to me - the ness-cli you’re running isn’t showing the commands it is running (i.e. S16, S00)

DEBUG:nessclient.client:Requesting state update from server (S00, S14)
DEBUG:nessclient.client:Attempting to connect
DEBUG:nessclient.client:Sending payload: '8300360S00E9\r\n'
DEBUG:nessclient.client:Sending payload: '8300360S14E4\r\n'
DEBUG:nessclient.client:Decoding data: '820003600000001b'
DEBUG:nessclient.packet:Decoding bytes: '820003600000001b'

Can you confirm you are running v0.9.14 please by running pip show nessclient

Name: nessclient
Version: 0.9.14
Summary: Implementation/abstraction of the Ness D8x / D16x Serial Interface ASCII protocol
Home-page: https://github.com/nickw444/nessclient
Author: Nick Whyte
Author-email: [email protected]
License: UNKNOWN
Location: /Users/nickw/.local/share/virtualenvs/test--MzFoo-H/lib/python3.7/site-packages
Requires: justbackoff
Required-by:

If you are not running the latest version, you can do so by running

pip install --upgrade 'nessclient[cli]'

If you were not running the latest version before, can you please re-run the command to obtain the debug data? Thanks.

ness-cli --log-level debug events --host alarm.home --port 8234

cryptelli · March 14, 2019, 12:15am

I can confirm that in the venv where HA is running the versions of nessclient is indeed 0.9.14.

aumatt · March 17, 2019, 10:31pm

@nickw444 just to let you know I updated to .90b on friday and my issue is now resolved, seems to be running great other than the reported Armed Home dropping back to disarmed. But other than that it seems really stable. Thanks heaps for your work.

cryptelli · March 18, 2019, 1:09pm

I’ve had to jerry-rig an input_boolean triggered on arming as a way of tracking when it’s armed for my automations which rely on the alarm to function.

Hopefully @nickw444 finds time to troubleshoot the issue since it was working flawlessly before this recent change, especially with the added scan_interval option, if I can provide any further debugging info just let me know.

nickw444 · March 19, 2019, 11:18am

Hi @cryptelli I’m still a bit suspicious about the logs you provided, even though you were able to confirm you are running 0.9.14. It will be very difficult to reproduce and debug the issue without being able to see what data ness-cli is sending to your IP module.

I would expect output similar to the following

DEBUG:nessclient.client:Requesting state update from server (S00, S14)
DEBUG:nessclient.client:Attempting to connect
DEBUG:nessclient.client:Sending payload: '8300360S00E9\r\n'
DEBUG:nessclient.client:Sending payload: '8300360S14E4\r\n'
DEBUG:nessclient.client:Decoding data: '820003600000001b'
DEBUG:nessclient.packet:Decoding bytes: '820003600000001b'
<ZoneUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ZONE_INPUT_UNSEALED: 0>, 'included_zones': []}>
Zone 1 changed to False
Zone 2 changed to False
Zone 3 changed to False
Zone 4 changed to False
Zone 5 changed to False
Zone 6 changed to False
Zone 7 changed to False
Zone 8 changed to False
Zone 9 changed to False
Zone 10 changed to False
Zone 11 changed to False
Zone 12 changed to False
Zone 13 changed to False
Zone 14 changed to False
Zone 15 changed to False
Zone 16 changed to False
DEBUG:nessclient.client:Decoding data: '8200036014000007'
DEBUG:nessclient.packet:Decoding bytes: '8200036014000007'
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED

when running the command:

ness-cli --log-level debug events --host alarm.home --port 8234

(Notice the verbose output of what is being sent to the IP module).

Also out of curiosity, and maybe to assist debugging, what is your scan_interval set to at the moment?

cryptelli · March 19, 2019, 1:18pm

I wasn’t really sure what to reply with initially, apart from supply a screen recording to show that it’s honestly not producing the information you’re looking for… when I had a strange idea to run that debug command in the docker container where I had tested the scan_interval which was running HA 0.89.0.dev0 and too my surprise it flipping displayed the same information you’re after, though only upon initial connection the alarm events still aren’t showing any verbose output.

The below debug log was run using HA 0.91.0.dev0 using docker.

root@56f41e46d2dc:/usr/src/app# ness-cli --log-level debug events --host IP --port PORT
DEBUG:nessclient.client:Requesting state update from server (S00, S14)
DEBUG:nessclient.client:Attempting to connect
DEBUG:nessclient.client:Sending payload: '8300360S00E9\r\n'
DEBUG:nessclient.client:Sending payload: '8300360S14E4\r\n'
DEBUG:nessclient.client:Decoding data: '820003600000001b'
DEBUG:nessclient.packet:Decoding bytes: '820003600000001b'
<ZoneUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ZONE_INPUT_UNSEALED: 0>, 'included_zones': []}>
Zone 1 changed to False
Zone 2 changed to False
Zone 3 changed to False
Zone 4 changed to False
Zone 5 changed to False
Zone 6 changed to False
Zone 7 changed to False
Zone 8 changed to False
Zone 9 changed to False
Zone 10 changed to False
Zone 11 changed to False
Zone 12 changed to False
Zone 13 changed to False
Zone 14 changed to False
Zone 15 changed to False
Zone 16 changed to False
DEBUG:nessclient.client:Decoding data: '8200036014000007'
DEBUG:nessclient.packet:Decoding bytes: '8200036014000007'
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED
DEBUG:nessclient.client:Decoding data: '820003600000001b'
DEBUG:nessclient.packet:Decoding bytes: '820003600000001b'
<ZoneUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ZONE_INPUT_UNSEALED: 0>, 'included_zones': []}>
DEBUG:nessclient.client:Decoding data: '8200036014000007'
DEBUG:nessclient.packet:Decoding bytes: '8200036014000007'
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
DEBUG:nessclient.client:Decoding data: '87008361240101180726033544ae'
DEBUG:nessclient.packet:Decoding bytes: '87008361240101180726033544ae'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 26, 3, 35, 44), 'type': <EventType.ARMED_AWAY: 36>, 'zone': 1, 'area': 1}>
Alarm state changed to ArmingState.ARMING
DEBUG:nessclient.client:Decoding data: '8700036122010118072603354430'
DEBUG:nessclient.packet:Decoding bytes: '8700036122010118072603354430'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 26, 3, 35, 44), 'type': <EventType.EXIT_DELAY_START: 34>, 'zone': 1, 'area': 1}>
Alarm state changed to ArmingState.EXIT_DELAY
DEBUG:nessclient.client:Decoding data: '87008361230001180726033553a1'
DEBUG:nessclient.packet:Decoding bytes: '87008361230001180726033553a1'
<SystemStatusEvent {'address': 0, 'timestamp': datetime.datetime(2018, 7, 26, 3, 35, 53), 'type': <EventType.EXIT_DELAY_END: 35>, 'zone': 0, 'area': 1}>
Alarm state changed to ArmingState.ARMED
DEBUG:nessclient.client:Decoding data: '8200036014000007'
DEBUG:nessclient.packet:Decoding bytes: '8200036014000007'
<ArmingUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ARMING: 20>, 'status': []}>
Alarm state changed to ArmingState.DISARMED
DEBUG:nessclient.client:Decoding data: '820003600000001b'
DEBUG:nessclient.packet:Decoding bytes: '820003600000001b'
<ZoneUpdate {'address': 0, 'timestamp': None, 'request_id': <RequestID.ZONE_INPUT_UNSEALED: 0>, 'included_zones': []}>

Don’t know if the above is of any use, but I’m not sure what else I can do from my end to get the results you’re after. Interested to hear your thoughts on this.

I lowered my scan_interval to 2s but haven’t been using it as it wasn’t in 0.89.2 and my attempt to override the default component wasn’t successful, only tested it briefly in the test instance I mentioned above. Figured I’d just wait until it was officially supported in 0.90.0.