After a brief hiatus, I finally got around to building out the links to the inline links downstairs. I added each device to plcd, and each of the buttons that will control them, then I started into linking them together. I found several issues within NetworkThread as it received the 'link' command. Mostly around how it handled the device IDs. I figured that as the Parametered class stored everything internally as strings, I could shove the text representation of the ID into the parameter and retrieve it as an integer.

I made the changes I described in the previous entry and plcd seems to be much more stable. It is still possible to crash it, but it's occuring much less frequently.

I also decided over the weekend to write a tool to talk with the PLM. This tool will enable me to get send bespoke commands to the PLM and to devices. Things that are useful to determine what is happening but really are unnecessary in a properly running system. Link database reads of the PLM for example, or getting extra data from a device.

Once again I am in a situation where I cannot get a decent uptime. Unfortunately I also cannot get core dumps from plcd either. I think it is time to explore how I am parsing commands from the network interface.

It appears to crash between two overnight events. The first event occurs as expected, the second does not. A quick look at the device control section of this site indicates that there is a problem with its socket communication which is in turn indicative of a plcd crash.

Over the last couple of days, I have been looking at how I can improve the definition of macros in the configuration file. First off I added the trigger element, then I decided to change how delays are defined. Previously it was simply a number of seconds, now to specify the delay you can write in either the number of seconds, the number of seconds and the number of seconds (MM:SS), or the number of hours, minutes and seconds (HH:MM:SS). When the file is written, the full HH:MM:SS is written out.

While this is a purely aesthetic issue, it does make the file easier to read by humans.

A good friend of mine asked me if the issues that I am facing with plcd are caused by poor design of the Insteon protocol. Here is my response to him.

As time has gone by and I have added more devices to each room, the UI became cluttered. To this end about a month ago I added the concept of device groups to collect devices together. I have used groups to aggregate devices by room.

Amongst all the new capabilities that have been streaming into plcd over the last few weeks, I have noticed that I have written similar code in several places. The code in question is that which gets the CommandFactory singleton instance and gets a command from it, reporting an error when CommandFactory doesn't recognize the command requested. Rather than litter the code with more of these, I decided that I would write a macro in the code called "GetCommandFromFactory".

With the rash of problems I am experiencing with the macro handling, I decided that I needed to fix them once and for all. Previously a Macro was a Device, the device level giving the command to respond to (ie 100% respond to an on, or 0 to respond to an off). During the re-architecture of this area, I have removed the izza relationship with Device, and have added a hazza relationship with a Command, this command is the trigger for the Macro.

As I mentioned previously the Parametered class while very useful also had limitations. Tonight I resolved the lack of namespaces, and developed the concept of the "Fully Qualified" parameter.

When a parameter is set or retrieved from a Parametered class, it is now required to have a namespace. The namespace is attached to the front of the parameter separated by the delimiter (currently '.') to provide the fully qualified parameter name. Once the fully qualified name is determined the parameter is stored or retrieved using the new string.

With the 'Parametered' class there are more and more cases where the configuration file does not know what data is stored, it only knows that some data might have been stored. This led to a function that simply loads each attribute into a parameter.

Unfortunately there is a problem with handling this naive. When loading the parameters some of them are duplicated. Take the following device description

<device PLMProtocol="I2" address="0f979800" group="Downstairs" name="KepadLincR8 - Downstairs main light"/>