karwas

Hello Techman, Zwave board I have installed in my ISY is unfortunately an old 300 series. Hence I run old firmware and UI, both versions 4.9.0 The Zwave library is Static Controller version 4.55 Static with Bootloader version 1.03 Yes, I do have 4 Kwikset 910 door locks and 3 Aeotec repeaters. They are working 50% of time, and 50% not so much due to connectivity errors. The overall physical network diameter is less than 100 feet. The maximum physical distance between devices is less than 25 feet. Any irregularities in network connectivity between devices could (and can) be mitigated by physically repositioning devices to be in closer distance with each other, but how close I should go? How many repeaters I need to install in the small network, where I just want to control 2 side yard gates, and the main door to the house? I was assuming that I do have a faulty antena or some source of radio interferences at my home, so I decided to investigate further with Razberry device (Raspberry Pi with Z-wave shield) I have included it to the network as Secondary Controller, but never demoted ISY from its role of Primary Controller. What I had found is still confusing and inconclusive, as I do have very low noise level (-90dBm/Ch#1; -100dBm/Ch#2 as indicated by Razberry radio tools), so no interference here, relatively high RSSI level on all devices (between -58dBm and -80dBm), so probably no antena issues, but very high ratio of corrupted frames with CRC errors (over 60% of frames with errors). Why??? All of those measurements are obviously taken from the perspective of Razberry Zwave shield, which is located 3 feet away from ISY, but I have no idea how to collect such RF performance data from ISY itself. Bottom Line: With 60% CRC errors no Zwave network layer functions are performing reliably due to excessive timeouts and retransmissions. So any analysis of "neighbors", "self healing" topology, etc. makes not much sense to me, as it is very random.

Hello, While troubleshooting problems with my Z-Wave network (subject of another post, yet to be written) I have encountered some very strange menu entry in my Z-Wave menu. I believe that my ISY is a primary controller (please note that I can still Include/Exclude nodes), yet it does not offer: "Shift Primary to another Controller", but instead offer an option to "Receive (Learn Mode)" To add to the confusion, the icon representing an option which is offered ("Receive (Learn Mode)") is a "Right Arrow", normally used for "Shift Primary to another Controller" I expected to see behavior of ISY to be somehow as described here: https://wiki.universal-devices.com/index.php?title=ISY_Z-Wave_GenII_-_Instructions#ISY_as_the_Primary_Controller_and_the_Z-Wave_network_is_empty but it is apparently different. Is my understanding wrong, or is this a bug? Thanks for clarification. Przemek

@LeeG Thanks for your explanation. This is basically a problem of "state management" in basically "stateless" protocol. Per your description, state (the knowledge which index to the table is used currently), can be disturbed by some asynchronous event. The simple remedy for this problem would be to modify "Get Next" in the way where it will convey an expected state. Basically, Get Next should have a parameter, which will be a last read index. Then, you will issue set of commands like this .... S: Get Next 31 R: Reply 32 S: Get Next 32 R: Reply 33 .... In this scenario, even if you would inject some disruption between those commands, next "Get Next" will put index into correct position. It is an old technique, it was used since (forever) in computer networks. (e.g. https://tools.ietf.org/html/rfc1157#section-4.1.3) Too bad, that we are always trying to reinvent the wheel, even if someone had done it already.... Przemek

Thanks! I will give it a try. I think I will use Raspberry Pi to do this, so I will be able to physically locate this tap in equipment closet where my ISY and PLM sits. In addition, Raspberry have enough processing power to write some protocol dissector, creating nice logs. On the other hand, it would be nice feature to have on ISY, to be able to do this in software. Przemek

@Paul All programs and scenes are working properly. Well, occasionally I see some glitches (red LED blinking) on new dimmers, but those are mostly related to Insteon communication issues. The problem with PLM link table is such, that I have just discovered that on two consecutive PLM Link table reads, I got different count of records. As nothing was changed in the network between those reads, it looked suspicious to me. So I executed "Show PLM Link Table" few more times, and every time I got different number of records. Przemek

@Paul High, and I believe correct, count is 141 Low vary -- sometimes 20, sometimes 116, some other time 67 Please note that I don't have 141 devices, but I do have several keypads Przemek

@Paul -- It was purchased few month ago (smarthome.com) and deployed to the network 2 or 3 months ago. Przemek

Hello, Is it possible to monitor all serial communication between ISY and PLM? Something like RS232 sniffer device or tcpdump on ethernet network? I was trying to elevate verbosity in Event Viewer to level 3 (Device Communications Events), but still don't see all commands, eg. All-Link-Record Response or others. Thanks, Przemek

I see... Ignore this, I was wrong. Edit: I have just looked in Insteon Developer Guide, and if I understand it correctly, this is a way how it works All communication from ISY to PLM starts with: (1) 0x02 (STX) octet as as start of message, then (2) 0x?? command code (3-??) command specific When PLM replies, it forms a message with: (1) 0x02 (STX) octet as as start of message, then (2) 0x?? reply code (3-??) reply data (last) 0x06 (ACK) to terminate message or when PLM is busy, it replies (1) 0x15 (NAK) to indicate negative acknowledgement. So, even if there are some concurrent processes happening at the same time, by looking at reply code and command code, ISY should be able to demultiplex such data streams Przemek

Hello, I have an ISY 994i connected to PLM 2413S and several (50+) various Insteon devices in the house. My understanding is that ISY communicates with PLM directly over serial cable. So I am surprised why whenever I try to read PLM Link Table, I am receiving different number of records. There is no Insteon network (powerline nor RF) involved in this scenario, so why is it unreliable? Any suggestions how to troubleshoot this issue? Thank you, Przemek