more on new dim/bright handlers

[James Sentman]

Thomas got it working so I expect that everyone else will be able to do so too now. I just wanted to write a little less hurriedly about it so that everyone can understand how it works and why I thought it would be a good thing to do. In the future I will try not to just copy and paste my own program changelogs into the release notes in a hurry anymore. It would have been better to just wait till this morning to do the release but I really wanted to get that mySensors stuff to Bob and Jeff.

I touched on this in the release notes, but here is way too much detail and an essay on the evolution of the X10 protocol with some actually useful info on “stacked” X10 commands to control more than one unit at a time if you wish to experiment with that. Skip ahead to the section "Here are the less rushed instructions.” if history and my ramblings trying to make sense of it for you are not interesting on a Saturday morning ;)

 
Back in the dark ages when there was only the X10 powerline there were very few devices that transmitted. Chances were pretty good that there was only 1 device that transmitted at the same time. You hit ON for a unit on your wired controller or the CM11 and then you sent some dimms to make that unit go to the proper level. They didn’t encode the unit number in that dim/bright packet, only the housecode. This was so that you could “stack” commands. Hit on for 3 different units in a row in the same housecode and then hit dim or bright and all those addressed units would all respond to the dim and brighten together. It also works for ON/OFF.

This still works and you can do this in XTension if you’re very brave. Use the send address verbs to address several units of the same housecode and then send a dim/bright/on or off command for the last one and they will all respond together. The XTension database doesn’t follow this and so after you do that you’ll need to dim the other units you addressed to the proper value with the “with no transmit” option added to the verb so that XTension will update the database level for them but not actually send the command on the powerline which would just make them dim further. In X10 land a dim command doesn’t send a value, it just causes the unit to go up or down by approximately 5% for each one received.

I used to do that for some things, but I don’t bother with it anymore. If you’re addressing more than 1 device the time between when you press the button and when something happens gets longer and longer as you’re sending more powerline commands that aren’t actually changing anything, and then everything goes together.  So you press the button and you stand there for a few seconds thinking, wait… did it work? Ah, and then the lights change. If you really want to mimic some scene capableness you can have all the lights in a room come on together this way but it’s not perfect and takes planning so that all the units you’d want to control together are on the same housecode. It works better for scripted timed things than for scripts set off by a remote or motion sensor because of the delay to set it up. If sunset in the living room takes 5 seconds to begin from when the script runs nobody will notice. But if you press a button and it takes 5 seconds before all the lights come on that feels like something is going wrong.

Now introduce the wireless X10 system and the powerline transceiver boxes and things start to get more complicated. With motion sensors and other remotes other things can happen in that period when you’re addressing units or sending dim/bright commands and blow up the stacked setup. You walk into the room and press the on button for a unit to address it, then you move to hit the dim button to set a level but in the meantime you’ve set off the motion sensor, or your dog has set off the one in the other room or your wife is trying to turn on the lights in her office, or... Several things could happen. The motion hit might be missed all together because of the fact that you’re now holding down the DIM button. The motion hit might make it onto the powerline between the time you addressed the unit and started hitting DIM and that will destroy the association between the unit you turned on and the dim if they are on the same housecode. Now all the dim’s you’re sending will try to go to the unit address of the motion sensor, or to whatever unit command got inserted into the middle of that process! Thats not useful. It becomes less and less reliable and more difficult to figure out just what the heck went wrong the more devices you add.

Now in the “lite" ages of separate address spaces we can receive wireless and send powerline separately and the 2 don’t mix unless we specifically tell them to. The confusion of all thats happening is the main reason we forcibly turned off automatic passthrough of wireless to wired all those years ago. The results were so unpredictable that it would have just frustrated everyone constantly. Unfortunately now it’s much more difficult to hold down the dim button to set the level of a lamp manually, but everything else works much more sensibly. 

XTension will pass dim/bright commands to the unit that is addressed to the remote button address, and if that unit is dimmable then it will adjust the levels. You can pass those changes from the ON script of the remote unit to a powerline unit, but is doesn’t work smoothly because of the repeat filtering required to reduce phantom receptions in the receivers.  dim “the powerline unit” to (future value) in the ON script of the remote unit would do it. Sort of… but again you run into that problem with being interrupted and redirected by any other wireless reception that happens in the meantime. It’s just not worth the frustration of having it only work part of the time. 

When we moved 5 or so years ago now I never setup another dim/bright wireless remote button. They have all been sitting there just bugging me by being useless. It’s so long since I touched any of the low level X10 handling code that I tend to think of it as invariant and never think to improve or change things ;) I have been doing a little refactoring in preparation for supporting some new wireless devices and it occurred to me that I could actually do something useful with those buttons. 



Here are the less rushed instructions.

Nothing changes unless you create this special unit. If you’re using dim/bright in the traditional way of letting the remote unit receive them and pass them on, that will still work. If the new unit is not found, the command will be processed as it always has.

Create a non-dimmable unit assigned to the proper wireless interface (optionally add multiple reception interfaces by clicking the “…” button next to the interface popup to make it more reliable) 

Set the unit to be X10-Wireless.

Set the unit address to be the housecode followed by “.DIM” for example: A.DIM or C.DIM or O.DIM 

Part of the confusion is that it’s .dim, so it’s kind of implied that there would be a .BRI as well, but there is not. 

When the bright button is pressed on any remote on that housecode the unit you just created will receive an ON command. When any remote on that house code sends a DIM command that unit will receive an OFF command.

All my 3 button stick a switches now are 4 button again! It’s not hard to think of scripts that can be useful from several different remotes on the same housecode. It does take a little planning, and if you have other things out there on the same housecode that are not related you might sometimes be confused as to who pushed what to make that script run, it’s still more useful now than before I think.


Thanks,
 James


James Sentman                       http://sentman.com		http://MacHomeAutomation.com