Blog Posts

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.

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.

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.

Remember that weird command that comes in during the middle of the macro send? Well, I figured I would use it to work on incoming command handling. Big mistake!!! This command turns out to be an ACK from the remote device with the new status in the "command one" byte. Not such a big deal I hear you say, except that it also doesn't send "command two" so if you are waiting for 9 bytes, you will wait for a very long time!

In the previous post, I mentioned a wierd message coming in part way through sending a second command in quick succession. Well, that's fixed properly now, it took a pretty substantial change as there was no way for the protocol to send a command up the queue at an arbitrary time. Now that can happen. So now, all I need to do is decode the command packets that are coming in from the PLM.

OPened socket 7
plcd[8648]: Network thread received: off for 00000001
Unhooking 7
plcd[8648]: Expanding Macro: outside lights
plcd[8648]: Transmission sending command: off to 00000001

I had at one point implemented "super verbose" output for the serial transport, problem was that it printed out every time ReadByte() was called, even if the underlying failed in "no wait" mode. This caused scads of output of the same character when the TransportThread was simply waiting for a command. The update ensures there is only output when the read is successful. Making things so much easier to follow...

So this evening during discussions with a friend, I have improved the debugging output for incoming messages in the PLMProtocol, now it is a better representation of what was sent in the packet. I also spent a little time adding a fix for a problem that had been irritating me for YEARS! Previously if the socket failed to bind at NetworkThread start, it was not retried. Now it is tried on a 1 second repeat until the socket is successfully bound.

Last night I did more work on plcd, I worked on getting decent debugging output from the protocol stack. You can add a debug attribute, and choose in there zero or more of "protocol" and "transport". Transport logs every character into and out of the transport as it is sent/received. Protocol gathers those characters into the logical lumps it deals with before logging them. At some point I will grab the output from syslog and demonstrate the differences.

In an instant of thinking out loud, I have the following musing.

I am thinking of adding "groups" of devices, so you could (for example) group all the devices in a specific room together. This will not affect the control of devices or anything, just enable a better presentation.

Finally my pile of new Insteon kit showed up. In the box are

1x KeypadLinc Dimmer - INSTEON 6-Button Scene Control Keypad with Dimmer, White
2x RemoteLinc 2 - INSTEON Wireless Keypad, 4 Scene
1x FanLinc - INSTEON Ceiling Fan and Light Controller, Fixture Module (Dual-Band)
1x HouseLinc - INSTEON Desktop Software with USB Interface (Dual-Band)
2x Skylink Wireless INSTEON Motion / Occupancy Sensor
2x SwitchLinc Relay - INSTEON Remote Control On/Off Switch (Non-Dimming), White
3x SwitchLinc Dimmer - INSTEON Remote Control Dimmer, White
2x RemoteLinc 2 - Visor Clip and Tabletop Stand

Pages