Blogs

After many years of using XML for the configuration file, I decided that it was time for a change.

Previously plcd was dependent on xerces-c to provide the DOM parsing and creation of the on disk configuration. This worked very well and was stable. I have never been fully happy with the XML format the I settled on and have been thinking about rewriting it for a while. Instead of using XML again, I chose to use YAML instead.

I had a short while over the weekend and decided that plcd needed to become more secure...

Until now, plcd has relied in obfuscation in its dealings with authentication, and bearing in mind that this is about the worst way to do it, I decided that there needs to be some form of real authentication involved. I have decided to use a password field in the network thread which will store the password hash.

I have just realized that there have not been too many updates this year, predominantly because there has not been much happening in the world of plcd! Since the crashes appear fixed, I have not needed to make any changes to the code. I can't think of too many other things I want to change and with time being a finite resource, I have not been just fiddling for the sake of it.

I want to write an Android client so that I can use my tablet as a controller, as well as perhaps embedding super cheap tablets in places that require high density control like the exit doors for example.

As the month of February has progressed, it really does appear that the previous problems with crashing have been fixed. The current uptime has been since the first of the month, previously unheard of!

I am pretty confident that this one is done. Finally I will be able to concentrate on other things needed I really want to make the Android client I promised myself when I got my tablet

With the changes I made yesterday (changing from write to send) it made it through the night, I have since added a line of debug output so I can detect if this was the issue with all of my crashes, but I am pleased this one is done.

As regular readers may realize, I have had problems with it crashing with no messaging. The last two nights, it crashed in a write call with a SIGPIPE signal.

Now, I don't routinely trap signals for the same reason that catch (Exception) is a bad idea, namely they generally mean something bad happened and everything needs to stop so it can be fixed. There are exceptions to this rule of thumb of course, but generally it's no bueno.

As it becomes more and more stable it's becoming more and more common that the only need for downtime is to reload the configuration file.

The reload command will be received from the network thread, and sent to the engine. The engine will cause the ConfigHolder to drop it's configuration and re-read the xml file.

As the ConfigHolder is accessed from multiple threads, this process will need to be mutexed to ensure that there are no attempts to access the class while this process is going on.

As time has gone on (and looking at the blog, it's been a lot of time) I decided that it would be great if plcd somehow knew that two devices were linked at the device level (ie directly).

As this is an Insteon concept, I decided it was the PLM protocol's responsibility to inform the engine that switching device A on also meant that device B turned on as well. So I added the parameters to the configuration file as "PLM.LinkedTo" followed by an incrementing number, so "PLM.LinkedTo0" is the first, followed by "PLM.LinkedTo1" etc.

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.

Pages

Subscribe to RSS - blogs