kk7ds / pynx584

Python library and server for talking to NX584/NX8E interfaces
GNU General Public License v3.0
29 stars 26 forks source link

Some help #78

Closed rstrouse closed 1 year ago

rstrouse commented 1 year ago

I have installed the software on a pi4. The alarm panel is an NX8 connected to an NX-584. I have a WizNet 110SR connected to that at 192.168.1.118:5000. This setup currently works on Vera to but using the this software I get no zones returned.

Here is the console output.

pi@pi4:~ $ sudo nx584_server --connect 192.168.1.118:5000 --debug
2022-11-20 12:58:31,207 main INFO Ready
2022-11-20 12:58:31,215 _cache DEBUG reading /root/.cache/python-entrypoints/21d615d294701119988d75ff4251d0ff358d86f77576b26196b1e6bbac9b2016
2022-11-20 12:58:31,216 controller INFO Loaded extensions []
2022-11-20 12:58:31,218 controller DEBUG Connecting...
 * Serving Flask app "nx584" (lazy loading)
 * Environment: production
   WARNING: This is a development server. Do not use it in a production deployment.
   Use a production WSGI server instead.
 * Debug mode: off
2022-11-20 12:58:31,227 _internal INFO  * Running on http://127.0.0.1:5007/ (Press CTRL+C to quit)
2022-11-20 12:58:53,808 _internal INFO 127.0.0.1 - - [20/Nov/2022 12:58:53] "GET /zones HTTP/1.1" 200 -
2022-11-20 12:58:53,815 _internal INFO 127.0.0.1 - - [20/Nov/2022 12:58:53] "GET /partitions HTTP/1.1" 200 -
2022-11-20 13:00:40,642 controller ERROR Failed to connect: [Errno 110] Connection timed out
2022-11-20 13:00:40,643 controller DEBUG Waiting 5 sec before retry...
2022-11-20 13:00:45,648 controller DEBUG Connecting...
2022-11-20 13:02:58,882 controller ERROR Failed to connect: [Errno 110] Connection timed out
2022-11-20 13:02:58,883 controller DEBUG Waiting 10 sec before retry...
2022-11-20 13:03:08,893 controller DEBUG Connecting...

Any clues in what I may not have set up correctly?

kk7ds commented 1 year ago

Sure seems like your pi4 can't reach the SoL device. The timeout is just it trying to connect, it isn't even doing anything yet.

rstrouse commented 1 year ago

I can ping 192.168.1.118 from the pi4.

kk7ds commented 1 year ago

Yeah, ping isn't the same thing. Not even the same protocol :)

A firewall between the two can allow ICMP and not TCP, or anything else.

Try telnet 192.168.1.118 5000. You'll probably have to install it, but unlike nc it will tell you what it's doing. I'd guess you'll see something like this:

Trying 192.168.1.118...

and then an eventual timeout.

rstrouse commented 1 year ago

Yeah I was already installing telnet when you posted. It does timeout but I do not thing the WizNet has a telnet server on it. That thing is really old. What are the adapter requirements and what might you recommend?

https://www.wiznet.io/wp-content/uploads/wiznethome/S2E%20Module/WIZ100-105-110SR/Document/WIZ110SR_UM_v210e.pdf

kk7ds commented 1 year ago

The use of telnet here is not to talk to an actual telnet server, but just a raw socket on your port 5000. That's all that is required. Any device that does a transparent socket-to-serial proxy will work fine.

I think I use 5000 in some of my examples - just to be clear, you've configured it for incoming TCP on port 5000 right?

rstrouse commented 1 year ago

Yes it is configured for port 5000. Interestingly enough I opened the WizNet configuration program and hit the save button and started to get this.

2022-11-20 13:41:31,384 controller ERROR Failed to decode a line; reconnecting: 'utf-8' codec can't decode byte 0x84 in position 0: invalid start byte
2022-11-20 13:41:31,385 controller WARNING Seeking (discarded b'\x06' 06)
2022-11-20 13:41:31,386 controller WARNING Seeking (discarded b'\x01' 01)
2022-11-20 13:41:31,387 controller WARNING Seeking (discarded b'X' 58)
2022-11-20 13:41:31,389 controller WARNING Seeking (discarded b'\x13' 13)
2022-11-20 13:41:31,390 controller WARNING Seeking (discarded b'\xf0' f0)
2022-11-20 13:41:31,391 controller WARNING Seeking (discarded b'\t' 09)
2022-11-20 13:41:31,392 controller WARNING Seeking (discarded b'\x00' 00)
2022-11-20 13:41:31,393 controller WARNING Seeking (discarded b'\x00' 00)
2022-11-20 13:41:31,394 controller WARNING Seeking (discarded b'\x00' 00)
2022-11-20 13:41:31,395 controller WARNING Seeking (discarded b'\xfa' fa)
2022-11-20 13:41:31,396 controller WARNING Seeking (discarded b'\x8f' 8f)
2022-11-20 13:41:33,878 controller WARNING Seeking (discarded b'~' 7e)
kk7ds commented 1 year ago

Is your panel in binary or ASCII mode?

rstrouse commented 1 year ago

How does one tell? Looking at the bytes above I would guess that output is binary.

kk7ds commented 1 year ago

One tells by inspecting the configuration of the panel. If you're not intimately familiar with that part, it's likely that you won't get the zone information you're looking for as most panels configured by default or by security companies don't have much enabled.

And yes, that's clearly not ASCII, but that doesn't mean it's sane NX584 binary protocol data either. I run ASCII on my panel so I can parse it by hand when needed. Someone recently added some binary support, but I don't know what it looks like by heart enough to know if what you're seeing is that, or different garbage from your SoL device.

rstrouse commented 1 year ago

When I bought this house. Brinks had the panel set up. I called them to open it back up and they wanted a $400 visit to open it up. So I just bought a new board and flew them the bird. I primarily use the alarm for sensors and almost never arm it.

Looking at the manual I did not change it from binary to ascii and binary is the default.

kk7ds commented 1 year ago

I literally did the same thing, but with a local company. Including the bird :)

So, if you want to use binary you need to put this in your ini file:

[config]
use_binary_protocol=True
rstrouse commented 1 year ago

Where is this file located?

kk7ds commented 1 year ago

It should be generated when you first run, or you can specify the path. It's described right in the README:

https://github.com/kk7ds/pynx584#config

rstrouse commented 1 year ago

If it is supposed to be in the /bin/local then it is not getting generated. The readme say that it creates it on the first zone but we are not getting to that point.

Can I just create a config.ini in the bin/local?

kk7ds commented 1 year ago

Yes, it says "generated once the controller reports the first zone name". That's clearly not going to happen for you without specifying the protocol. So, yes, just create it and point it at the file with --config. I dunno where you're seeing bin/local anywhere.

rstrouse commented 1 year ago

usr/local/bin is where pip3 tucked it on Bullseye. I created a config.ini and referenced it on the command line and got no change at first. That is until one of the doors were opened and then I got reporting for that zone. None of the other zones have reported yet.

kk7ds commented 1 year ago

In general the thing is event-based, so that's expected. If you set max_zone, the controller should ask the panel for status (and names) on the zones at startup. Unless that is enabled though the panel will refuse the query.

rstrouse commented 1 year ago

Thanks I will mess around with it this evening.

rstrouse commented 1 year ago

I got it all working. Just so you know I still get the same result if I try to telnet to the WizNet. Resetting the adapter and upgrading the firmware made it come to life. On the pynx584 side I needed to have it set to binary and all the reporting started to happen as expected.

kk7ds commented 1 year ago

The wiznet thing probably doesn't have a connect backlog, which means if anything is connected to its one open port anything else will hang or time out when trying to connect. So if something else is connected, that'll be the behavior. You meantioned a vera, so perhaps the vera was holding that connection initially and your reconfig kicked it out and nx584 won the next one? That would exclude the telnet test as well, as would nx584 itself.

So sounds like we can close this?

rstrouse commented 1 year ago

Yessir. I believe you are correct. I will be looking at a different adapter in the future.