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.
I then unlinked one of the RemoteLinc devices in the master bedroom from the fan, and linked the button to the PLM. Now, plcd gets to hear the commands this button generates. I added the fan section of the FanLinc to plcd so that it can be controlled. During this process, I 'found' the link that had been made to the OutletLinc in the the living room. Not sure what is going on there, but this device has issues linking and unlinking. I have decided that it is currently doing what I want it to, so I am simply going to leave it alone. Now came the fun part.
I added a pair of macros for the RemoteLinc buttons, one to go faster, one to go slower, I associated them with the on and off commands. By touching the bottom of the fan housing where the light kit would be I discovered that I can feel the motor responding to the FanLinc. I decided that I would empirically derive the number of '*onestep' commands to switch from one state to the other, in this process I found that the gap I was aiming at between off and level 2 was not the same as the gap between level 1 and level 3. In other words, I cannot simply send a the same number of 'brightenonestep' commands to change between levels. To get around this, I created more macros responding to the RemoteLinc, using Conditions to select which one to execute. Adding in a "fan shadow" device and sending it discrete 'dim' commands ensures that each Condition can accurately determine the fans state.
Well, that was the plan. I discovered quite early on that over the last few months, the Macro work had not received the same amount of care and attention as other elements. First of all some of the attribute names were completely incorrect. Instead of looking for 'state' the parser was looking for 'command'. On fixing this, I could confirm that the Condition was now checking for the correct device state. Then came the realization that the 'effect' elements while building the correct command where not adding the parameters to the command. I solved this by adding the parameters to the effect and simply reading the entire attribute list into the command parameters. This causes the parameter list to be longer than necessary as certain parameters are stored into the object directly and then also stored into the parameters. Once this was fixed, I discovered that the Macro effects were not carrying the specified parameters. This turned out to be the EngineThread getting new commands from the factory instead of cloning the commands that had been set up when the Macro had been read from the configuration file.
Once all of these details had been resolved, each macro was executed at the right time and the correct parameters for each command were set. Now I just need to make the macros work as I would expect them to.