Cannot find serial device in configuration

[gabeale]

I have successfully installed nxgipd program on Pi Zero and properly configured the serial port that in my case is /dev/ttyUSB0. Unfortunately I'm not able to get serial port working because not found by the program. Any idea? Thanks! Alex

[tjko]

What is the version of Rasbian (or Raspberry Pi OS)? And version of Mini-XML? (dpkg -l libmxml-dev)

[tjko]

I just checked in change to fix compile issue against Mini-XML 3.x (5123887c520010ee9716d7ffc06a88e071447c80), that might help with your issue as well?

[gabeale]

Hi, thanks for the very quick feedback. Raspberry Pi OS is raspbian bullseye In Release.

If now I install Mini-XML 3.3.1 shall I recompile nxgipd program? If yes shall I first remove version without the fix 5123887? Any particular command for doing this?

[gabeale]

I have installed library Mini-XML 3.3.1 and recompiled nxgipd with the fix 5123887 but I get the following message:

What I'm doing wrong?

[tjko]

Sounds like you don't have nxgipd process running on the background?

It needs to be running as nxstat and nxcmd tools communicate with it via IPC.

To setup nxgipd run as a "service" on background there is contrib/nxgipd.service file to copy under /etc/systemd/system/

Then you can enable (so that it starts automatically after reboot) and start the service by running

systemctl enable nxgipd
systemctl start nxgipd

[gabeale]

Thanks for the information. I have followed your suggestions but service cannot start. I receive the following error message:

Is it linked to some user missing permissions?

[gabeale]

For your info, I have created manually file and folder for nxgipd.log because not there. Then I launched the service but I receive the following error message: I have set my Aritech CS575 RS232 serial port either as "printer" or as "serial". The third option is "Serial STU". I'm sure that serial communication in "printer" mode can work because tested with Nodered. Unfortunately by this method (i.e. Nodered) I can get very limited information (e.g. arm, disarm and opened zones) and no control. Any suggestion?

[tjko]

You may want to run nxgipd on foreground at first, to confirm it is able to connect and talk with panel ok... Simply launch it from shell with -v flag (and no -d flag so it stays running on foreground).

Double check your panel settings/programming. Settings must match between nxgipd.conf and what is configured in the panel settings (i.e. protocol must match and baudrate, etc...). And at least on NetworX panels you need to configure enabled transition messages and commands for the serial interface (as listed in the README), before it works correctly.

I've only ever used (GE) NetworX panels with nxgipd, but I recall someone reported CS575 working fine... Unfortunately, I don't have details how it needs to be programmed to get it working...

[gabeale]

I tried also this and debug through minicom just to see the exchanged messages:

It seems no messages are there! For your info I enabled all the available transition messages as well as commands as per your Git. Also baud rate, parity etc. match. I'm wondering what should be the first message that nxgipd sends to detect panel model.

[tjko]

You may want to use terminal emulator (tio is probably easiest to use), to make sure you have working connection to panel, panel should be sending messages when there is activity (zone tripped, etc...) that you should see if you have terminal emulator connected.

Something like:

tio -b 9600 /dev/ttyUSB0

(in tio you can press ctrl-t + h to enable hex mode, to see if panel is sending binary data that is not 'printable'...)

You can change the "log" setting in the config file to 3 , to see the serial messages being sent received, as well...

[tjko]

When the nxgipd starts, it will at first send NX_INT_CONFIG_REQ (0x21) message to panel. Based on the error you saw, looks like panel did not respond to that message.

Common reason for this is serial cable is not wired correctly or panel is in 'binary' mode and nxgipd is configured for 'ascii' mode....

[Dogora]

I can't speak at all for the Aritech CS575, but the NX-584 serial communication module has jumpers on it that will switch RXD and TXD between pins 2 and 3 on the 9-pin serial connector. The factory default is reverse of what you probably want. Or, you can use a crossover ("null modem") cable (or adapter) that swaps the two signals rather than a straight-through cable.

You can easily check which pin is TXD with a voltmeter. The voltage between TXD and GND (pin 5) will be something like -5V or -10V, while the voltage between RXD and GND will be basically zero. Obviously, TXD on one end needs to be connected to RXD on the other.

[gabeale]

Tested the emulator as you suggested:

Communication with /dev/ttyUSB0 is ok (tested the partial closing that excludes volumetric sensors 001÷005 (i.e. Zones). Alarm panel communication type is set to "Printer". The other two options are: "serial" and "serial STU": I don't know the exact meaning of this. If set to "serial" I get this:

I'm not able to acknowledge it, I suppose this is the reason why it comes every two seconds!

If I set the Panel to " Serial STU" I don't get anything! However when I set back to "Printer" I get log of previous bad communication (due to "Serial STU" mode) plus all the arming and disarming tests.

In conclusion: the only way to get communication with /dev/ttyUSB0 is setting the Panel communication to "Printer" but in this way I'm not able to establish the communication using nxgipd program.

Any suggestion?

P.S. log in /etc/nxgipd.conf is "3"

[tjko]

Looks like "serial" is the NX-584 "ascii" protocol (and perhaps "Serial STU" is the "binary" protocol....)

So, you should use that "serial" mode on the alarm panel, and configure protocol to "ascii" in nxgipd.conf.

If panel is still not responding, it could be that TX pin from the computer side is not connected to RX pin on the panel side....

For the "log" setting try increasing it, maybe it needed to be 4 (or 5) to show the serial comms...

[tjko]

Also, make sure nothing else is using the serial port at the same time (as nxgipd process).

Something like: fuser -v /dev/ttyUSB0

[gabeale]

I tested that nothing else is using the serial port at the same time:

but still I'm not able to establish communication with alarm panel using nxgipd.

I have also checked the wiring and it seems to be ok (i.e. grounded and Tx and Rx crossed).

Actually panel message when set to "serial" is always "002D00031C1433000032ADFC7337" whose meaning is not clear to me.

I'm also wondering whether sending the "ACK" message stops it but I don't know how to send in ASCII ("ACK", "0x0a", "0x1d"?)

I have some doubt about the protocol whether it should be standard RS232 or TTL-RS232 (voltage levels are different)

The USB to serial adapter I'm using is this:

https://www.amazon.it/gp/product/B01LY97ZM5/ref=ppx_yo_dt_b_asin_title_o08_s00?ie=UTF8&psc=1

and it works perfectly when Panel communication is set to "printer". Any idea?

[Dogora]

I will hazard a guess that the messages you see in "serial" mode are keypad messages, not automation messages. nxgipd needs the automation messages. Check your panel programming.

Can you describe your panel hardware in detail? Are you using the CS586 to get a DB9 serial port? Can you link to manuals for your exact hardware?

[tjko]

If you set "log" setting in the config file to 4, nxgipd process will log messages received/sent in the log file:

...
2023-03-27 19:52:19: nx_receive_message(): got message 01 (01)
2023-03-27 19:52:19: nx_send_message(): reply received 01 (01)
2023-03-27 19:52:19: nx_send_message(): message 28 sent
2023-03-27 19:52:19: nx_receive_message(): got message 08 (08)
2023-03-27 19:52:19: nx_send_message(): reply received 08 (08)
2023-03-27 19:52:19: nx_send_message(): message 27 sent
2023-03-27 19:52:19: nx_receive_message(): got message 07 (07)
2023-03-27 19:52:19: nx_send_message(): reply received 07 (07)
2023-03-27 19:52:19: nx_send_message(): message 24 sent
2023-03-27 19:52:19: nx_receive_message(): got message 04 (04)
2023-03-27 19:52:19: nx_send_message(): reply received 04 (04)
2023-03-27 19:52:19: nx_send_message(): message 24 sent
2023-03-27 19:52:19: nx_receive_message(): got message 04 (04)
2023-03-27 19:52:19: nx_send_message(): reply received 04 (04)
2023-03-27 19:52:19: Program started: nxgipd v1.1.1beta (2023-03-27)
2023-03-27 19:52:19: NX-584 Firmware version v1.06
2023-03-27 19:52:19: Getting system status...
2023-03-27 19:52:19: nx_send_message(): message 28 sent
2023-03-27 19:52:19: nx_receive_message(): got message 08 (08)
2023-03-27 19:52:19: nx_send_message(): reply received 08 (08)
2023-03-27 19:52:19: Panel ID: 12
2023-03-27 19:52:19: Panel Model: NX-8-V2
2023-03-27 19:52:19: panel communication stack pointer change: 0 -> 140
2023-03-27 19:52:19: Partition 1 Active
2023-03-27 19:52:19: Partition 2 Disabled
2023-03-27 19:52:19: Partition 3 Disabled
2023-03-27 19:52:19: Partition 4 Disabled
2023-03-27 19:52:19: Partition 5 Disabled
2023-03-27 19:52:19: Partition 6 Disabled
2023-03-27 19:52:19: Partition 7 Disabled
2023-03-27 19:52:19: Partition 8 Disabled
2023-03-27 19:52:19: AC power ON
2023-03-27 19:52:19: Voltage present interrupt active
2023-03-27 19:52:19: Querying partition statuses...
2023-03-27 19:52:19: nx_send_message(): message 27 sent
2023-03-27 19:52:19: nx_receive_message(): got message 07 (07)
2023-03-27 19:52:19: nx_send_message(): reply received 07 (07)
2023-03-27 19:52:19: Partition 1 status change: Ready, Chime Mode On
2023-03-27 19:52:19: run_partition_trigger() called
...

(Looks like for more detailed debug you may need to set the "DEBUG" macro to 1 and recompile... It's been like 10 years since I last did any debugging, since haven't had any problem with GE/Gaddix panels....)

[tjko]

You can change following in nx-584.c:

#define DEBUG 0

to

#define DEBUG 1

And recompile...that should enable more detailed debugging....

[gabeale]

I changed debug level to 1 and recompiled the program. I also set log settings to 4. Attached you can find the full log since the beginning.

nxgipd.log

See also nxgipd verbose when Panel is set to "serial" communication:

the "IN" message should be the above mentioned recurring "002D00031C1433000032ADFC7337" message and not a real Panel response to inquiry message.

I'm also attaching nxgipd verbose when Panel is set to "printer" communication:

In this case there isn't any "IN" message from the Panel.

@Dogora: Connection has been realized by J18 pins 1 (Panel Tx), 2 (Panel Rx) and 4 (GND) as per attached scheme:

On the Pi Zero side I have connected the above mentioned USB to serial device configured as follows (standard RS232):

The second RS232 option is TTL-RS232 as attached scheme:

Since I noted that Panel is communicating in "Printer" mode with standard RS232 (i.e. first scheme) I'm using that.

I also tested voltage levels between Rx (Panel Rx) and Gnd is almost null whereas between Panel Tx and Gnd there is some voltage when message is sent but since this is very quick I cannot make a precise measure of voltage level using my meter.

[tjko]

Looks like in "serial" mode it sends hex strings (like the NX-584 gateway protocol does in "ascii" mode), but checksums don't match, so seems like this must be some other protocol...

You may want to test setting protocol in nxgipd.conf to "binary" and panel to that "Serial STU" mode. Or did you test that combination already?

[gabeale]

Here is the test with nxgipd.conf set to binary, Panel to "Serial STU"

logfile is this:

Automation module Protocol is described in the attached manual.

Automation Module Protocol.pdf

Really I don't understand why it is not working.

[tjko]

This seems to be some different protocol (compared to NX-584: http://www.increa.com/reverse/nx-8e/Caddx_NX-584_Communication_Protocol.pdf)

I think report that nxgipd works with this panel must have been with system that has NX-584 Home Automation Module installed (and using serial port on that module)....

[Dogora]

I think we've proven interface voltage levels are not your issue. The USB-RS232 dongle takes care of that. The serial UART pins on the Pi Zero 2-row header are 3.3V logic level, which is not compatible with RS232 voltage levels. Another option is an add-on board like this one.

Seems to me that getting an NX-584 is easier than rewriting the parser. Mine has been a solid performer for the past 9 years.

[gabeale]

Thank you guys for the support, have you an idea where to buy the NX-584 module?

[Dogora]

I looked around and they are hard to find these days.

On the other hand, I tried to parse your message, "002D 0003 1C14 3300 0032 ADFC 7337", with the posted Automation Module Protocol document and it doesn't fit. The first byte (2 digits) should be the message length, and the last byte should be the checksum, which also doesn't match. I still wonder if there's some setting you've missed to get the automation protocol turned on.

[gabeale]

You are right: there is a checksum mismatch. For your info I'm attaching Panel Installer Manual (is in Italian language).

Centrali Serie Comfort.pdf

Configuration tree diagram is shown on page 80 of the pdf, Fig.39 whereas on page 110 is described the submenu 2.6.3.1 for the transmission type: you can select serial printer or home automation protocol (this is divided in two: "serial" and "serial STU" that should stands for a proprietary protocol, see snapshot taken from pg 6 of Automation Protocol Manual).

Serial printer works perfectly and I can parse messages for Panel activations and bypassed zones. It seems to be one-way communication only (as expected by a printer).

If Panel communication is set to standard "serial" I'm expecting a standard RS-232 communication as indicated above in the Automation Manual excerpt.

If Panel communication is set to "serial STU", this should be the proprietary PHAST protocol for which it is required additional hardware like the following Superbus 2000 Automation Module.

Superbus_2000_automation_module.pdf

It is similar to NX-584 Home Automation Module for NX-series panels.

I coming to the conclusion that my USB to serial converter is not working properly.

Any idea how to simple test the Tx and Rx of my USB to serial dongle?

[Dogora]

There are two simple tests you can do to check your dongle. First, connect the USB dongle to the USB port and leave the DB9 end disconnected. That DB9 is probably pins on your dongle, so either a cable or gender changer is useful because sockets are easier to play with. Find two short pieces of small wire that fit into the DB9 sockets. Loose is better than tight.

Using the 2 wires, connect your voltmeter's black lead to pin 5 and the red lead to pin 2 and you should measure 0V. Move the red lead to pin 3 and you should see negative voltage, ranging from -5V to -12V. My dongle reads -9.6V. This means the transmitter works.

Next, bend one piece of short wire so you can put one end into pin 2 and other into 3. Run tio and type something. You should see everything you type. Remove the wire and you won't see anything when you type.

[gabeale]

Thanks for suggestions, I'll let you know the test results. Reviewing the protocols once more I noted that NX one has null parity

whereas my Panel protocol has odd parity

Is it possible to change the parity in nxgipd config?

[gabeale]

@Dogora this is just an update: I have tested USB dongle as per your suggestions. Voltage between GND and Rx is 0 VDC whereas between GND and Tx is -5.65 VDC hence it is working properly. Moreover making a short-circuit between Rx and Tx and running "tio" I receive properly the same messages typed-in hence also in this case USB dongle is working properly.

[Dogora]

I took a quick look at the code, and you will have to modify the file misc.c to change the parity setting. It's in the openserialdevice function. Looks like t.c_cflag needs to be also OR'ed with PARODD and PARENB, at line 202 in the latest version. "man termios" gets you the details (on a Linux machine). I have no way to verify this.

[tjko]

I made quick change (143339a0b85b6306fbf866777c51ca5031aa6ac1) to add serial "mode" parameter in nxgipd.conf this allows specifying data bits, parity, and stop bits. Default is "8N1" if setting is not defined in nxgipd.conf.

It should now work doing something like this in the configuration:

  <serial>
    <device>/dev/ttyUSB0</device>
    <speed>9600</speed>
    <mode>8O1</mode>
    <protocol>ascii</protocol>
  </serial>

Mode is three characters:

1 = data bits. (8, 7, 6, 5) 2 = parity (N = none, O = odd, E = even) 3 = stop bits (1, 2)

(this was only tested with "8N1" since thats what my panel uses)

[gabeale]

Thank you guys for continuous support. I have downloaded the updated repo (143339a) and recompiled the program. Result is here attached:

It seems that Panel is not listening at all! Maybe it really requires the Automation Module in between to communicate with the external world.

[gabeale]

Hi guys, this is just to update you. After a long web search and several testing I understood the reason why nxgipd program is not working in my case (GE Interlogix Panel CS575): Communication Protocol is "X10" and not "NX584 RS232"! Now the matter is whether it is possible to parse messages recovering the structure of nxgipd or if it is necessary to switchover to a completely different program, like for instance heyu or others that I still have to look for. In the latter case it would be a pity because nxgipd would be easier to be integrated in Homeassistant that I'm using for all the other sensors in my house. If you had any advise it would be great for me!