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.

So I ultimately decided that the atsunset configuration file will not have a list of commands, it doesn't belong in there. The configuration file will just have the lat/long pair for the location. Command line will be something like...

     -f configuration file (default /etc/atsunset.xml)
     -o offset, default seconds but a trailing h, m or s will change the unit
     -d output useful debugging information and skip the file call to "at"

so an example would be

./atsunset plccommandline -a 00000001 -c on

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

If you look back far enough, 'plcd' was written in C and was refactored over time into C++.

One upshot of this being that there are many instances of doing things the old C way rather than using an STL construct. No where is that more apparent than in the use of char* strings.

I'm going to fix this by using std::string for strings wherever possible.

In light of macros providing for delayed commands, I think I am going to have to implement a "cancel" command.

The purpose of this will enable a future command to be cancelled ie pull a delayed off command out of the queue, to extend an on period.

Using this will mean that when a motion detector detects motion, it will cancel any outstanding off commands from the previous detection, guaranteeing that the light will remain on for the expected delay time.


Subscribe to RSS - blogs