The most recent crash dropped a core file!

Upon debugging it appears that something sent some bogus message over the network. When the network thread decoded the message it turned out to contain no valid sections. The code then tried to access the first section to determine the command that was sent and dereferenced a null pointer.

I fixed this specific issue, but thinking more about it I need to significantly improve NetworkThread's general robustness.

Not sure what is causing it, but there have been many instances of 'plcd' crashing over the last few days. At the moment it does not seem to cause a core file unfortunatly. I will research "atcrash" and try to determine the cause of the issue. I have a sneaking suspicion there is some power line traffic from some I2CS device that is confusing PLMProtocol. If that is the case, it should be relatively easy to debug and fix.

Now that the dining room is sorted, I am going to finish up the installation of the devices I recently bought.

Upstairs, I installed OutletLinc devices just outside the front door, I have put them in covers that are rated for "wet when in use" so hopefully that satisfies code.

Downstairs, I installed a new box near the old one to hold the InLineLincs for the overhead kitchenette lights (relay) and the eyeball lights (dimmer). I used an old bit of wire removed from the attic to connect this box to the existing box and this gives me plenty of room to house everything in j-boxes.

As mentioned here the SwitchLinc install in the dining room needs fixing. This evening I did this, and finally managed to fish the new switch loop through the wall. I removed the old wire completely and ran the new wire through the ceiling box. Now the dining room light switch has line, neutral and load wires running into it from the ceiling box.

Having rambled on about I2CS for at least two posts now, I have decided on a final resolution...

In this post I detailed a sorry tale of failing to install a SwitchLinc which ended up with the end of my fishtape stuck in the wall and an indirect control system.

Now that I have Parametered devices, I can switch back to working with I2CS.

First thing is to determine which device is an I2CS device versus which is I2. This is accomplished by sending a GetEngineVersion command to the device and examining the response. If Command2 in the reply is 0x01 then we have an I2 device, if Command2 is either 0x02 or 0xff then we are looking at an I2CS device. Once the determination is made, then the protocol is stored in the device for future reference.

With Commands successfully using the Parametered class, it now remains to convert Devices to the use the new parameter system.

Devices have the added complication of needing to write their parameters to and read the values from the configuration file. To achieve this when the Device is constructed it is passed the pointer to the ConfigHolder. This pointer is passed down into the constructor of Parametered. When a parameter is stored if the pointer to ConfigHolder is not NULL, then WriteFile is called to cause the configuration file to be rewritten.

As mentioned here I have evolved the parameter handling from Command into its own class.

I may have previously commented on the need for arbitrary parameters for commands. If not then there is a need for commands to use arbitrary parameters. These are on top the command's target and type. This is for things like dim level in dim commands or responders in link commands.

I implemented this as a std::string, std::string map in the 'Command' super class, and provided translator functions to enable inserting and pulling integer values.


Subscribe to RSS - blogs