Attempting to control individual LEDs and a complete revamp of device handling within the PLM protocol!

Submitted by toftat on Sun, 2012-07-15 18:49.

While trying to control the individual buttons on a KeypadLinc, I had to implement the extended command handling to transmit the commands to control the LEDs. This went a lot easier than the standard command work, due to the lessons learned through that process. However, the documentation which led me to believe that the LEDs are individually controllable is incorrect, and it turns out that you actually send a bitfield. For this to work properly, it would be necessary to read the existing LED state, and 'or' in the desired change, involving 2 powerline commands.

Changes to command transmission

Submitted by toftat on Thu, 2012-07-12 21:17.

After the final command sending post here it has been working properly. I recently turned of the transport logging, and found it broken again. There must have been a race condition that was hidden by the slowdown caused by the extreme amount of logging.

Subgroups in devices

Submitted by toftat on Tue, 2012-07-10 12:12.

With the revelation that every single device and button needs to be linked to the PLM to report its status, it became apparent that plcd needs to deal in 32bit addresses. Insteon uses 24bits for each device, and plcd uses an additional byte for the controller group. For example

0xAABBCCGG

Device grouping: The protocol changes

Submitted by toftat on Sun, 2012-07-08 19:00.

Back on 6/22 in this post I mused about adding a group parameter to the Device class and into the corresponding config file entry. At some point over the last week (actually it was 7/4 according to git) I made the configuration file changes to add the groups.

Tonight I added the group to the DEVICE network thread command, when sent from plcd. It now reads

DEVICE:&ltaddress&gt:&ltname&gt:&ltgroup&gt:&ltstate&gt:

Receiving command flow

Submitted by toftat on Sat, 2012-07-07 18:00.

With the discovery of the need to link each controller group to the PLM, it is simple to determine that a button has been tapped or a switch switched. The problem remains that in most cases there are devices linked to that controller which do not report their state to the PLM.

Receiving commands from the Insteon network

Submitted by toftat on Sat, 2012-07-07 06:00.

As time has passed, I have been trying to understand how the PLM will present commands that are sent through the Insteon network. Through testing I have discovered that there are no commands received by the PLM for any device or group that is not linked to the PLM.

To overcome this limitation, it is necessary to link all controllers to the PLM (PLM is a responder). While it is only necessary for one controller group per device to be linked, by linking all controller groups, it guarantees the message gets sent to the PLM.

Dropped bytes from reads

Submitted by toftat on Fri, 2012-07-06 17:00.

A few posts ago I was having issues with commands not having all the bytes I was expecting. It was causing issues with sending commands as I would on occasion not get "command 1", it was causing issues with receiving commands as I would not get some parts of the command, most of the time "command 1". Generally it was being a HUGE PITA.

Final command sending post

Submitted by toftat on Tue, 2012-07-03 23:41.

Using the timeout read, getting status works properly now for all devices, in fact, I have added it to the PLMProtocol start up to get the status for all devices. Setting the timeout to 5 seconds ensures that the read doesn't block for ever when the device doesn't respond. This fixes the issue I saw when trying to query status of RF only devices (remotes and motion detectors). Next thing on the list of stuff to do will be adding "Group" to the device commands, allowing UI's to gather related devices together.

New PowerLineTransport method: bool ReadByte(unsigned char *cByte, int iTimeout)

Submitted by toftat on Mon, 2012-07-02 11:27.

I have just added a new function, to the powerline transport interface. Previously you could read either blocking or non-blocking. Which has up until this point satisfied all the needs. However, last night I was messing about with loading all devices status at startup, and found that the wireless devices (remotes and motion sensors) do not send a remote ack at all, so I wait for it forever, hence the new "block with a timeout" function, if I timeout, I can just abort the process, the timeout can be set for a "while" (5 secs or so) and recovery managed accordingly.

Revisiting command sending

Submitted by toftat on Sun, 2012-07-01 21:05.

After the hassle of interpreting incoming commands, and the uncertainties that surround even sending commands, I decided that I needed to get command sending buttoned up.

cowshed.us

toftat's blog