PYNX584 on RPI4-Zones status strange behaviour-Arming not possible

[gveloce]

FIrst of all congrats to the developer and contributors of this piece of magic. It was a critical factor to move to Home Assistant from my prehistoric Home Automation sw. Having a CADDX-GE NX8 (not E) version 1.2 and the NX584 addon board I followed the wiki instructions and was rather straightforward to install it. a. the first thing I noticed is that in order to get zones status after a system reboot is to have the zones 'tripped' (on-off) first. Not doing this all zones show as faulted running the command nx584_client summary (until they are tripped) Is this somehow by design or something is wrong? b. Most of the nx584_client commands I tested worked except the arm command (note: nx584 server running on localhost and client commands run on localhost as well) Here is the command and the error message $ nx584_client arm-stay Traceback (most recent call last): File "/usr/local/bin/nx584_client", line 175, in 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, int(args.partition)) TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'

Just to note in addition that the integration with Home Assistant seems working well in general, except again from the Arm command that is failing with this error message shown in the debug log under /home/pi. 2022-05-06 05:27:16,755 controller DEBUG Sending queued [62, 0, 1] 2022-05-06 05:27:17,033 controller DEBUG Parsing raw ASCII line b'011F2021' 2022-05-06 05:27:17,033 controller DEBUG Received: 31 Message Rejected (data [])

Can someone pls help on solving these issues? Do you need more info/details from my side?

TIA GV

[kk7ds]

I think by (a) you mean some HA behavior, which I can't really help with. For (b) you need to pass a --partition=1 (or something) to arm. It should probably default to 1 if not provided, and it should definitely provide a more useful error message, but that's why it's failing.

[gveloce]

Hi Dan and tx for the quick response. Very very appreciated. Actually by (a) I refer to nx584_client command, not to HA. After RPI reboot running the command I get this output: pi@homeassistant:~ $ nx584_client summary +------+-------------+--------+--------+ | Zone | Name | Bypass | Status | +------+-------------+--------+--------+ | 1 | Entrance | - | False | | 2 | Radar LR | - | False | | 3 | Out LR | - | False | | 4 | In LR | - | False | | 5 | Out Kitchen | - | False | | 6 | In Kitchen | - | False | | 7 | Out KJ BR | - | False | | 8 | In KJ BR | - | False | | 9 | Out A BR | - | False | | 10 | In A BR | - | False | | 11 | Radar Corr | - | False | | 12 | Radar A BR | - | False | | 13 | WC | - | False | | 14 | Out OMXH | - | False | | 15 | In OMXH | - | False | | 16 | Smoke | - | False | +------+-------------+--------+--------+ In order to get the real status of the zones I have to trigger them, eg open and then close a door. Then pynx584 gives the right status. Here is the example for zone 6 pi@homeassistant:~ $ nx584_client summary +------+-------------+--------+--------+ | Zone | Name | Bypass | Status | +------+-------------+--------+--------+ | 1 | Entrance | - | False | | 2 | Radar LR | - | False | | 3 | Out LR | - | False | | 4 | In LR | - | False | | 5 | Out Kitchen | - | False | | 6 | In Kitchen | - | True | | 7 | Out KJ BR | - | False | | 8 | In KJ BR | - | False | | 9 | Out A BR | - | False | | 10 | In A BR | - | False | | 11 | Radar Corr | - | False | | 12 | Radar A BR | - | False | | 13 | WC | - | False | | 14 | Out OMXH | - | False | | 15 | In OMXH | - | False | | 16 | Smoke | - | False | +------+-------------+--------+--------+ The output is the same even if I specify the partition (only 1 partition used) pi@homeassistant:~ $ nx584_client summary --partition 1 +------+-------------+--------+--------+ | Zone | Name | Bypass | Status | +------+-------------+--------+--------+ | 1 | Entrance | - | False | | 2 | Radar LR | - | False | | 3 | Out LR | - | False | | 4 | In LR | - | False | | 5 | Out Kitchen | - | False | | 6 | In Kitchen | - | True | | 7 | Out KJ BR | - | False | | 8 | In KJ BR | - | False | | 9 | Out A BR | - | False | | 10 | In A BR | - | False | | 11 | Radar Corr | - | False | | 12 | Radar A BR | - | False | | 13 | WC | - | False | | 14 | Out OMXH | - | False | | 15 | In OMXH | - | False | | 16 | Smoke | - | False | +------+-------------+--------+--------+

I understand this is strange as I did not find any such issues in here so really puzzles me. And this making very skeptical to implement my security concept within HA (same behaviour).

Sorry for keeping you busy with this and hope you any other else may help me to troubleshoot this.

TIA GV

[kk7ds]

I'm not sure what you mean. When you start up nx584, all the zones are False because that's their steady state. Until the NX8 tells us that one of the zones is faulted, we have no idea that it is. Are you saying you have one zone faulted while you restart pynx584 and think it should immediately know that the zone is faulted? I'm not even sure we can poll the system for zone status at startup, I'll have to look. It's been a long time since I read the protocol document, but.. it's intended to be event-driven.

[gveloce]

Again thnx for the light-speed reply!!! This is what I mean. After a reboot nx584_server is started (in rc.local), Then running the nx584_client command all zones show as Faulted. In order to get their real status I have to open/close them. Then nx584_client gets/displays the zones real status. If this is by design I have to accept it. But it is a bit risky in case of an unexpected reboot of my PI as the alarm concept in HA may be affected. BTW I am not experienced in HA and this topic so maybe I am wrong...

TIA GV

P.S. Arming with nx584_client command worked after I activated in addition Secondary KP function parameter :) After that arming also works from within HA. This may help others with this issue.

[kk7ds]

I think maybe you're confusing the terminology.. "Status=False" means "not faulted". "Status=True" means "faulted". Faulted means the zone is in its non-normal state, so "door is open" or "motion detected". I'm guessing you have some zones that stay faulted for a long time, like a window?

I looked at the protocol doc and there is a command (24h) for requesting zone status, so I can see if that's easy to add.

[gveloce]

Apologies. You are right. My bad... I confused "False" with "Faulted" :( I rephrase my last post not to confuse others: .... After a reboot nx584_server is started (in rc.local), Then running the nx584_client command all zones show as FALSE. In order to get their real status I have to open/close them....

Your idea with the zone status command sounds promising. Hope you find some time to work it out.

Sincere thanks for your support!

TIA GV

[kk7ds]

Can you try the referenced commit? If that works for you I'll generate a new build.

[gveloce]

Dear Dan I see you reference two commits. One for the zones and one for the partition. Glad to try, but -sorry to say- I dont know the way to get them applied on my system. If it helps i installed the PYNX584 on my RPI4 by using the commands sudo pip3 install pynx584 sudo pip3 install pynx584 --upgrade sudo usermod -a -G dialout pi
and here the linux version running Linux homeassistant 5.15.32-v7l+ #1538 SMP Thu Mar 31 19:39:41 BST 2022 armv7l GNU/Linux

TIA GV

[kk7ds]

Try:

pip3 install git+https://github.com/kk7ds/pynx584

[gveloce]

Thanx Excuse my ignorance but this command will install the two coconuts provided above? TIA GV

[kk7ds]

By "coconuts", did you mean "commits"?

The command above will install pynx584 from this git repo, so you'll get the updated stuff (although you probably need to add --upgrade to what I gave above). Normally pip installs from pypi, which is where I'll push this once you confirm it works for you, but the above will let you install the latest version from the repo here.

[gveloce]

Hi again I have re-installed pynx584 as per your instruction above and looks you nailed it mate!!! According to the logs and verified with nx584_client command all zones status is now discovered after a startup :) Also HA gets the zones status accordingly.

The only 'strange' thing -that I think it was happening also before- is that the partition status is not shown by nx584_client command as a trailer line below zones status immediately but only after 5-7 mins. Is this normal? (btw same behaviour from HA side as well) Will keep on checking rebooting etc and may come with more details

AGain sincere thanks for your persistent support and at your disposal for any further help from my side.

TIA GV

[gveloce]

Let me add more info on my above post about partition status: after a few reboots i realize this is consistent, i mean partition status is not discovered on startup. Again similar to zones status, partition status is discovered after trigering an event as arm-disarm. Does it give a hint where the issue can be ? At your disposal for any additional info or testing

TIA GV

[kk7ds]

Do you have the "Set Clock / Calendar" command enabled? That's the first thing that the controller loop does on startup, before anything else. When the time gets set, we get back system status message that also indicates which partitions are enabled, and then the status for those is fetched. So if time set is disabled, then you won't get back the system status right away, until something causes the panel to do so.

So, can you check if that is enabled and if not, see if that resolves it?

This is what my startup looks like:

2022-05-08 08:00:50,826 controller DEBUG Sending queued [59, 22, 5, 8, 8, 0, 1]
2022-05-08 08:00:50,915 controller DEBUG Parsing raw ASCII line '011D1E1F'
2022-05-08 08:00:50,915 controller DEBUG Received: 29 Positive Acknowledge (data [])
2022-05-08 08:00:51,015 controller DEBUG Parsing raw ASCII line '0C8804000000000200000A019F45FA'
2022-05-08 08:00:51,016 controller DEBUG Received: 8 System Status (data [4, 0, 0, 0, 0, 2, 0, 0, 10, 1, 159])
2022-05-08 08:00:51,016 controller DEBUG System status received (panel id 0x04)
2022-05-08 08:00:51,016 controller INFO System asserts Valid partition 1
2022-05-08 08:00:51,016 controller INFO System asserts Phone line monitor enabled
2022-05-08 08:00:51,016 controller INFO System asserts Voltage present interrupt active
2022-05-08 08:00:51,016 controller INFO System asserts AC power on
2022-05-08 08:00:51,016 controller DEBUG Requesting partition status for 1
2022-05-08 08:00:51,116 controller DEBUG Parsing raw ASCII line '118A9FB9F700000508080101060A015258864639'
2022-05-08 08:00:51,116 controller DEBUG Received: 10 Log Event (data [159, 185, 247, 0, 0, 5, 8, 8, 1, 1, 6, 10, 1,
 82, 88, 134])
2022-05-08 08:00:51,116 controller INFO Log event: Time set at 2022-05-08 08:01:00

The "59 22 5 8..." message is "set the time", I get back a "positive acknowledgement" then the system status and "time set" log event.

[gveloce]

tnx for the hint First I confirm Set Clock/Calender is activated on my NX584. I restarted a couple of times the rpi and could find the command "Sending queued [59, 22, 5, 8, 8, 0, 1]" in the logs. Then I configured for NX584 the "Zones Snapshot" option and restarting the RPI i was able to see the "Sending queued [59, 22, 5, 8, 8, 0, 1]" in the log... But not 100% sure if this is somehow related. Another strange thing is that after the command nx584_client summary still was not showing at the end the partition status like but after few (5-8) mins re-running the client command the line for partition status is now shown BUT as partition 2! (I have only 1 partition in my system) See below: nx584_client summary --partition 1 +------+-------------+--------+--------+ | Zone | Name | Bypass | Status | +------+-------------+--------+--------+ | 1 | Door Entry | - | False | | 2 | Radar LR | - | False | | 3 | Out LR | - | True | | 4 | In LR | - | False | | 5 | Out Kitchen | - | True | | 6 | In Kitchen | - | False | | 7 | Out KJ BR | - | False | | 8 | In KJ BR | - | False | | 9 | Out A BR | - | True | | 10 | In A BR | - | False | | 11 | Radar Corr | - | False | | 12 | Radar A BR | - | False | | 13 | WC | - | False | | 14 | Out OMXH | - | False | | 15 | In OMXH | - | False | | 16 | Smoke | - | False | +------+-------------+--------+--------+ Partition 2 disarmed

This is weird I know so not sure what to do to further help troubleshooting this and hope the effort I make you spend is valuable for some other PYNX584 users ....

TIA GV

[kk7ds]

That behavior is mentioned in another issue, although I've never seen it myself (also only one partition here). Can you pastebin a full debug log so I can have a look? Maybe stop nx584, delete the debug.log, then start it and let it run for a few minutes before you capture and paste the log.

The "protocol" document for these is detailed in some places and not in others, so a lot of the behavior is determined by my own setup, which may or may not be indicative of everyone's. Seeing your log would help (and probably help me close that other issue as well).

[gveloce]

Hi Ok. pls allow me to answer back by tomorrow EOD

TIA GV

[gveloce]

Hi as promised here is the debug log after a restart. https://pastebin.com/7h9q7C7Y (not experienced with pastebin, hope it works...)

Here s also the output of the command nx584_client summary --partition 1 +------+-------------+--------+--------+ | Zone | Name | Bypass | Status | +------+-------------+--------+--------+ | 1 | Door Entry | - | False | | 2 | Radar LR | - | False | | 3 | Out LR | - | True | | 4 | In LR | - | False | | 5 | Out Kitchen | - | True | | 6 | In Kitchen | - | False | | 7 | Out KJ BR | - | False | | 8 | In KJ BR | - | False | | 9 | Out A BR | - | True | | 10 | In A BR | - | False | | 11 | Radar Corr | - | False | | 12 | Radar A BR | - | False | | 13 | WC | - | True | | 14 | Out OMXH | - | False | | 15 | In OMXH | - | False | | 16 | Smoke | - | False | +------+-------------+--------+--------+

TIA GV

[gveloce]

Hey just found out something weird that may help. When the front door opened (alarm being disarmed) it triggered the partition status!!! Here the log part at that time.
2022-05-09 19:52:29,303 _internal INFO 127.0.0.1 - - [09/May/2022 19:52:29] "GET /events?index=53&timeout=60 HTTP/1.1" 200 - 2022-05-09 19:52:33,396 _internal INFO 127.0.0.1 - - [09/May/2022 19:52:33] "GET /partitions HTTP/1.1" 200 - 2022-05-09 19:52:39,962 controller DEBUG Parsing raw ASCII line b'09860000000000010082139A' 2022-05-09 19:52:39,963 controller DEBUG Received: 6 Partition Status (data [0, 0, 0, 0, 0, 1, 0, 130]) 2022-05-09 19:52:39,964 controller DEBUG Partition 1 ['Open period', 'Delay trip in progress (common zone)'] 2022-05-09 19:52:39,967 _internal INFO 127.0.0.1 - - [09/May/2022 19:52:39] "GET /events?index=54&timeout=60 HTTP/1.1" 200 -

TIA GV

[kk7ds]

Yeah, that makes sense if it's an entry door, because the partition goes into delay trip when an entry door is faulted. I'm puzzled why you don't get a system status from the time set, but I pushed something yesterday (85152e683a86ffbb96509059e520c90cdedf7b95) to make it explicit. Can you upgrade to the latest in the repo again and see how that behaves? Another debug log with this applied would be appreciated (your other pastebin worked fine).

[gveloce]

Yeah!!!!! Good news! Performed the upgrade and I got partition status during startup!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Here the pastebin https://pastebin.com/a2m1jX33

btw i disabled "zones snapshot" and "partition snapshot" on my nx584 board as they should be irrelevant

Congrats mate and sincere tnx!!! GV

[kk7ds]

Cool, I'll push an update to pypi today after work so everyone else will get it. Thanks for your patience and help debugging.

[gveloce]

thanx for your persistent support mate! Cheers GV