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.

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"/>

As mentioned previously I am going to work on getting the fan to work. I have added the 'dimonestep' and 'brightenonestep' commands to get the fan (and other device groups) to change dim levels. These were fairly easy, the process is well understood.

The Insteon FanLinc is a pretty slick piece of kit. It sits in the canopy of the fan, it is dual band and it is a dimmer for the light kit and has fan speed control. On the down side, the fan speed control is really designed to be operated from multiple controller groups, like a KeypadLinc with each of the four buttons set to a different speed. Trying to control it from a dimmer is frustrating, you have to watch the fan change speed and stop when you hit the desired speed.


Subscribe to RSS - blogs