Unable to Arm System - Throws Error
Closed this issue · 17 comments
When attempting to arm my panel via the nx584_client, I am receiving the following errors. This is on an NX-584E serial module, connected to an NX-8v2.
I have successfully got Home Assistant reading sensor information, but arming the alarm has not been successful at this point. In Home Assistant, when I type in my code, and press 'ARM AWAY', the code pad issues one long beep and nothing happens. if I hit the ARM HOME button, nothing happens at all.
I have the 584E setup as per: #5
Excerpt from executing an nx584_client arm command:
user@HOST:~# nx584_client arm-exit
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/urllib3/connection.py", line 141, in _new_conn
(self.host, self.port), self.timeout, **extra_kw)
File "/usr/local/lib/python3.4/dist-packages/urllib3/util/connection.py", line 83, in create_connection
raise err
File "/usr/local/lib/python3.4/dist-packages/urllib3/util/connection.py", line 73, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/urllib3/connectionpool.py", line 601, in urlopen
chunked=chunked)
File "/usr/local/lib/python3.4/dist-packages/urllib3/connectionpool.py", line 357, in _make_request
conn.request(method, url, **httplib_request_kw)
File "/usr/lib/python3.4/http/client.py", line 1090, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python3.4/http/client.py", line 1128, in _send_request
self.endheaders(body)
File "/usr/lib/python3.4/http/client.py", line 1086, in endheaders
self._send_output(message_body)
File "/usr/lib/python3.4/http/client.py", line 924, in _send_output
self.send(msg)
File "/usr/lib/python3.4/http/client.py", line 859, in send
self.connect()
File "/usr/local/lib/python3.4/dist-packages/urllib3/connection.py", line 166, in connect
conn = self._new_conn()
File "/usr/local/lib/python3.4/dist-packages/urllib3/connection.py", line 150, in _new_conn
self, "Failed to establish a new connection: %s" % e)
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0xb62ce830>: Failed to establish a new connection: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/requests/adapters.py", line 440, in send
timeout=timeout
File "/usr/local/lib/python3.4/dist-packages/urllib3/connectionpool.py", line 639, in urlopen
_stacktrace=sys.exc_info()[2])
File "/usr/local/lib/python3.4/dist-packages/urllib3/util/retry.py", line 388, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='localhost', port=5007): Max retries exceeded with url: /command?cmd=arm&type=exit (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xb62ce830>: Failed to establish a new connection: [Errno 111] Connection refused',))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/bin/nx584_client", line 175, in <module>
main()
File "/usr/local/bin/nx584_client", line 152, in main
do_arm(clnt, args)
File "/usr/local/bin/nx584_client", line 46, in do_arm
clnt.arm(mode)
File "/usr/local/lib/python3.4/dist-packages/nx584/client.py", line 32, in arm
'type': armtype})
File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 521, in get
return self.request('GET', url, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 508, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 618, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/requests/adapters.py", line 508, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=5007): Max retries exceeded with url: /command?cmd=arm&type=exit (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xb62ce830>: Failed to establish a new connection: [Errno 111] Connection refused',))
This is the early connect, so it shouldn't have anything to do with the operation (i.e. arm) that you're doing. Is nx584_server running? On the same machine?
Thanks. I suspect its because I was not explicitly specifying the host:port. I am running the client and server on the same machine (RPi v1) but not on the loopback address. I managed to get it to arm by specifying the partition and host explicitly with the standard 'arm' argument.
nx584_client arm --partition 1 --host 192.168.x.x:5007
using arm-stay, arm-exit or arm-auto arguments are hit and miss.
Once armed, I then attempt to issue the disarm command and it doesn't complain, but simply will not disarm.
nx584_client disarm --master XXXX --host 192.168.x.x:5007
I am still unable to get HASSIO to do what it is supposed to do though and I will play more with this later this evening. I am running HASSIO on a separate RPi (v3) and connect to it via host and port. The binary sensors in HASSIO work really well, but arming/disarming from the nx584 alarm_control_panel platform will not work as I would expect it to. The status updates correctly in the alarm_control_panel component if I manually arm/disarm the panel so its communicating ok.
I am going to have a bit more of a play this evening and see what I can narrow down.
Finding ample doco on this has proven difficult so I think I may write some more doco once I have it all sorted for you to consider as an addition to this repo.
Yeah, if not on the loopback address, then you'll need to provide the connection details (as you figured out).
For reference, we arm and disarm our system almost exclusively via nx584 and it works 100% of the time for me. I've never seen it be flaky, so I'm not sure what to suggest. The only exception is that if you try to arm it with one zone faulted it will fail to do so (although you should hear the keypads make a distinctive error tone).
Are you sure you have all the commands enabled on your system? Arm and Disarm each have a "with passcode" and "without passcode" variant and both need to be enabled.
OK thank you. I don't have the "without passcode" ones enabled so I will enable those later on and test again. The zone faulting while activating may explain some of the intermittent behaviour so will test more thoroughly again. I'll report back with my findings.
Thanks for the support thus far.
Arming uses the without-passcode variant, so if that's working it should be enabled. Disarming requires the passcode though, so maybe that's what isn't enabled if disarming never works?
Anyway, let me know what you find in that regard...
Will do. Thank you.
Any thoughts on why Home Assistant requires a code to be entered before arming (keeps the arm buttons greyed out without a pin code being entered)? At least that is my experience.
I haven't used HA in a while, but IIRC the UI just assumes that you need a code for everything. I'm sure that's something that could be changed if someone brings it up (or supplies a patch).
FYI - These are the features I have enabled on the NX584. I will enable the "Primary KP function w/o PIN" later this evening and test again. IIRC I had enabled all features at one point without luck, however I will be more specific in subsequent testing.
Anything else you feel that I should have enabled?
Hmm...so the arming seems to be relatively consistent...providing no zone is currently tripped. I can achieve this by executing:
nx584_client --host 192.168.1.57:5007 --master XXXX arm
In fact zone tripping seems to impact a number of commands, haven't quite figured out which ones but that seems to explain some of the intermittent nature I think I am seeing.
Disarming has still got me puzzled and I am unable to get it to work just yet....getting late here so will have to call testing quits for the night before I upset everyone with the siren chirp.
Q'n: Does the disarm command require a partition to be specified? or is that an optional attribute?
nx584_client --host 192.168.1.57:5007 --master XXXX disarm
One thing I have notcied in my alarm panel config wa that by default, the 'program' user (Instaler/master) does not have the ability to arm/disarm (below). I will change this tomorrow and try some more:
You need the user info and set code things enabled if you want to be able to manipulate the users and passcodes remotely. Otherwise that looks like everything is enabled.
I think there is a separate flag to enable the program user to arm/disarm and do things like a regular user. For the sake of debugging, however, you should be using a regular user/code for your arming and disarming, not the program passcode.
The disarm client command doesn't pass the partition to the server, and the server assumes partition 1. This should be something you can specify in the client, I just probably glossed over this as I only have one partition. This is fixable if it's blocking you, but I don't think I've seen you trying to specify anything other than the first partition right?
Note that the arm command I'm sending is the "without passcode" variant, which the system maps to "User 97" when it emits the "partition was armed" event afterwards. So I imagine the --master you're passing to it is just being ignored, but I'm not sure why it would be working at all. Perhaps that's considered a secondary keypad function, since if quick arm is enabled, it doesn't require a passcode at the keypad.
Also, your examples show "--master", but you really mean "--master XXXX" right? The master thing takes an argument, so if you're not passing something there it's eating the next argument as the passcode :)
Thanks again. I had '< PIN >' in the command after --master I had quoted and it got obfuscated by GitHub for some reason. I have edited the post in the interest of future reference.
I will stick to using a specific user number for debugging as per your suggestion. If IIRC, some of the commands require the master code to be entered as a mandatory argument.
The partition specific disarming isn't blocking me at this point and I can come back to that at a later time. My goals with this are as follows:
- Allow HAss to be able to read the state of the alarm sensors - COMPLETE
- Allow HAss to arm/disarm the alarm system as part of an automation - PARTIAL (arm is working, disarm is not at this stage).
I will continue to debug and keep you posted.
OK...disarm is working now from within HASSIO, but not from the nx584_client CLI. As per your suggestion have stopped using the master code for debugging. However, the disarm command seems to require the master code it would appear (mandatory).
user@HOST:~# nx584_client --host 192.168.1.57:5007 --pin XXXX disarm
Master pin required
user@HOST:~#
Issuing the --master argument with pin accepts the command, however the alarm fails to disarm.
That doesn't seem right does it?
I have one more interesting thing happening in HAss whereby the 'arm home' button seems to arm away, yet the 'arm away' button does nothing. But that one can wait for now....maybe one for the HAss repo.
Sorry, I may have misrepresented my point earlier. You should be using the master pin in your testing, not the programming PIN. Later, you can use any user that has permission to disarm, but you'll pass that code with the --master argument. --pin is used for setting a user's pin.
Also, yeah, if HA isn't arming with the right type in the right situation, then that'd be a change needed in the nx584 driver within HA.
Ahh....that makes much more sense now and may explain everything. I was interpreting --master as the required --master code, not a user code/pin. All in the nomenclature I guess.
Issuing a user pin under the --master argument works perfectly.
I am going to try and put some doco together to add to the README.rst. It might help with some others in the future.
Okay, sorry about that. Clearly more docs are needed, and I'd be grateful if you want to help write some.
I wrote this to scratch my own itch, hoping to make it reasonably generic enough for someone else to use. I wrote the HA driver for it for a friend that hasn't moved past HA 0.14. I use nx584 itself every day, but in scripts I wrote long ago. So, a couple years later, here I am trying to remember it all to answer questions.
Thanks a lot for your patience and persistence :)
All good. You have done a fantastic job with this! I have just posted up some doco for your review. It is only fair that I can contribute something to the mix. The HA driver does need some work I feel. It would be great to extend the capability of the HA driver to do other things too. e.g.
- Allow zone bypasses to be set/unset from the HA interface
- Enable zone chimes
- Trigger auxilliary outputs (e.g. onboard relays) - not sure if this is possible.
- Displaying event history
Enabling this would be a complete game changer for this panel ecosystem. It would provide additional options over and above the more proprietary solutions offered by Networx/Interlogix etc that require the client-server architecture, meaning the entire remote management solution can be contained to a private network, using HA as the bridge and ruling out the zerowire man-in-the-middle architecture that is otherwise required by the more proprietary options.
I am not a python programmer, but I don't see this being too much work over and above the hard work that @kk7ds has already put into this library.
FYI - These are the features I have enabled on the NX584. I will enable the "Primary KP function w/o PIN" later this evening and test again. IIRC I had enabled all features at one point without luck, however I will be more specific in subsequent testing.
Anything else you feel that I should have enabled?
I've just started looking into this again as I was never able to disarm. What application have you used to pull down the details of the NX4/NX8?