Generic serial device - received data path

[Steve Horn]

While in the process of adding voice commands for echo/Alexa and my security system (which is a hoot, BTW) I discovered that the data stream from my Elk M1 was not going to the received data property of the alarm device. Data sent to the M1 works as it should. If I disable the hardware interface and instead monitor the COM port with Hyperterminal I can see the heartbeat data being sent by the M1. So I know the data is being sent by the M1 and being received by the COM port. This has happened before and either fixed itself ( ) or I unknowingly did something to repair it. So... What is the "path" of received data from hardware interface to the intended device. And yes, I have set the destination for received data in the hardware interface to the proper intended device.

[ScottBot]

Steve,

Great question. It's basically a Publish/Subscribe mechanism with a few twists.

A device can subscribe to any number of notification lists. A notification list is just a named list (global namespace) with an optional Filter option. For example, an X10 Device would subscribe to the X10 Reception list with a filter value of B3 (As an example of an X10 Device configured for House/Unit code B5.

When a hardware interface needs to send a notification, it sends a list of key/value data specific to the event to a specific notification list. It will use the appropriate filter also (so data from an X10 B5 device will use the B5 filter).

This allows data to be broadcast from the hardware interface to all devices listening for certain events. However, sometimes you don't want the data to be broadcast to every device. For Generic Serial setups, you usually want to tie a particular interface with a device so you direct the notification data to the right device. One way to do that is by using the Received Data Serial Device Destination property. It will act as a filter for the notification and only send it to the specified Device.

Another way that the notifications get filtered/directed is if the Restricted Notifications option is set in the hardware interface setup (option found under the Hardware Module Type button). If this option is set, the notification will only be sent to Devices that are configured to use the hardware interface that is broadcasting the event.

Hope that all makes sense and is helpful in some way. I'd check the value of the Received Data Serial Device Destination to make sure it's sending it to the correct Device. Also, if the COM port setup isn't right, it won't receive the data even if it's being sent by the hardware.

You can also enable a hardware interface trace to get a better view into what the hardware interface is actually seeing and receiving.

[Steve Horn]

Closure on this... sort of. After several unrelated reboots of the HB server, enabling tracing on the hardware interface for the Elk M1 (which indicated that data was being received), and heaven-only-knows-what-else that may have affected receipt of the data stream, but it started being passed to the alarm device's received data property. The "link" between the hardware interface and the intended device and received data property apparently was "broken", even though the hardware interface was created to send the received data to the proper device. I have no better explanation.Go figure...

[Steve Horn]

This has reared its ugly head again.
To refresh:
-The Elk M1 panel is sending heartbeat messages to the HB server every 60 seconds via serial RS232 port.
-Those messages in the past have been received by Housebot via the hardware interface (generic serial), presumably passed through the HDF file data, and passed on to the Received Data property of an alarm device
-Except not all the time. And not now.
-May work for months, then not.
-Data (commands to arm etc.) can reliably be sent to the Elk M1. EVEN WHEN THE RECEIVED DATA STREAM IS NOT WORKING!
-The heartbeat string can be reliably seen via terminal emulation program, EVEN WHEN ITS NOT BEING SEEN IN THE HB RECEIVED DATA PROPERTY.
-Nothing has changed (via humans) from working to not working.

How can this be?
Intermittent serial cable receive data line? Nope, you can see the heartbeat via hyperterminal program.
I've looked for ways to trace the path, or reception of incoming data. But my traces have turned up nothing. Nothing actually being seen by HB or bad trace setup?

I have no clue.

[ScottBot]

Steve,

The best way to get the interface trace is to enable the hardware interface trace on the generic serial device. It should show each character (IR byte) received.

There is a slight chance that it could be caused by a small memory leak that I fixed in the interface recently. Please try this interface plug-in to see if it works any better. Just unzip it and replace the existing dll in your plugins\interfaces directory.

[Steve Horn]

I initiated the trace of the HW interface (Never knew that was there), and replaced the GenericSerial.dll. I'm still not seeing the heartbeat on the trace. Although I can see data being sent to the M1 that I use to enable it via Alexa . I can disable the M1's hardware interface, open a terminal session via Hyperterminal and see the heartbeat. (I typed in error previously; the heartbeat is every 30 secs, not 60. But no matter...).

[ScottBot]

So you're not seeing the "Received character..." trace message showing the heartbeat. Do you see any other received data in the trace?

Double check the DTR/RTS flow control settings on the interface settings. It depends on what you are connected to, but I would try disabling both and see if it helps.

[Steve Horn]

No, not seeing "Received character.." for any received M1 transmission, including heartbeat. Once I start the HBserver, the (Naninck developed) M1 vbscript kicks in and sends a bunch of commands to the M1 to retrieve all the user, zone params, etc. I see all those "Sending..." and "Writing..." Messages. But no replies from the M1, which would normally respond by sending replies to all the queries. After that, I SHOULD see the heartbeat within 30 secs. (I tried disabling that vbscript and restarting HB to see if the data queries were affecting/blocking the return of any data. Nope, still no heartbeat.)

Just tried rebooting the alarm panel. No difference - nothing seen by HB.

I have checked the hardware configs - baud rate, 8N1, no handshake (at all; software or hardware) etc to make sure it agrees with the Elk manual. Of course that would not explain why it USED TO WORK, and with no human initiated changes, doesnt now.
... And of course, why I can see the data stream with a terminal emulator.

Looked at the HDF file for the alarm - agrees with all the expected parms on the hardware deivice config screen.

I want to try to find a cheap/free serial port monitor program to see what is happening when the HB hardware interface is enabled. And compare that to a Hyperterminal-type connection.

[ScottBot]

I want to try to find a cheap/free serial port monitor program to see what is happening when the HB hardware interface is enabled. And compare that to a Hyperterminal-type connection.

You might try running the 32-bit version of API Monitor. It should show Read/Write File events that might show something. I've found that it likes to report parameter issues with the calls when they are fine (it might be the difference between actually reading/writing a file and writing to the com port with the same api)

[Steve Horn]

I think its been handled. Using a port monitor, I compared what was happening in a HB connection vs. what was happening in a hyperterminal session. I noticed that in the terminal session the RTS indicator was live whereas in HB, not so much. Changing the RTS parm in the HW config from disabled to enabled "turned on" RTS (which is really a "ready to receive"). and data is now being received as well as being sent. What is odd is that this HW interface worked at all before, because I had not changed the RTS parm since day one. Further, the Elk M1 doc says no flow control is required or expected; They just "send and pray". So, fingers crossed...

[Richard Naninck]

My settings have been like below for the last eight years without any problems:

115200 - 8 - None - 1 - Disable - Disable with a command terminator 0D 0A

[Steve Horn]

So have mine. That's why this is so odd. But looking at the status "lights" in the port monitor and comparing to the working terminal session, the RTS was clearly off, and changing it in HB to enabled turned it on and data spewed forth... And still is. Odder still, the cable between the M1 and HB server uses only 3 wires: transmit and receive data and ground. Handshake lines arent event used. I'm thinking that the M1 is always sending data - it can't see the RTS status because there isn't an RTS line. But HB is not opening the port until RTS is enabled. I need to work with the port monitor more and try to understand all the internal port traffic going on under the covers.

[ScottBot]

I wonder if Windows automatically updated your serial port driver and 'fixed' something that changed the behavior.

[Steve Horn]

Thats possible. Always something being downloaded and updated.
I've looked at the port monitor's outputs briefly. Most of which i don't understand yet. But one panel looks promising, in that it is a English sort of version of whats going on with each character sent or received, as well as intermediate transactions relating to the port. I need to work with it more to see if I can spot differences between when HB RTS is enabled vs. disabled.

[Steve Horn]

I've noticed something, twice now. First time I thought it was a fluke. Now I'm not so sure. I need to try to duplicate. Anyway, the change of the RTS parm from 'disable' to 'enable' seems to have fixed the connection issue described above. However, I have caught the HB hardware config for that device reverting to 'Disable' RTS, which kills the connection to the device. Between this issue and another serial port assignment issue (described in another post), I've been in and out of the hardware device configs a lot. So I'm not ruling out something I might have inadvertantly done. But it SEEMS that a change of the parm is not being saved, or possibly being overwritten by something that is saved. Need to try to duplicate...