Mac Home Automation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=====Dealing With Power Failures=====
If you use a UPS there are some things you should know about the setting on the Mac before you trust the system to restart after the UPS runs out of power.

First off it should be understood that unless you have a very large backup battery longer power outages will run most batteries into the ground and the UPS will shut down.

Most UPS's are meant for the short power outages that are self correcting as power is rerouted to the grid through other systems. They are usually good for about 15-20 minutes depending on the power requirements.

The settings for the UPS in the Mac preferences allow for a "polite" shutdown when the UPS power gets too low to keep the computer going. This is nice in keeping the system from being corrupted on a shutdown for lack of power.

The main problem in this scenario is that when the computer does a "polite" shutdown it will not restart when power is restored even if the "restart after power failure" is checked. A restart after a power failure is only good for a "impolite" shutdown that happens when there is no UPS attached to the system.

For this reason a computer that is required to run for home automation must not do a "polite" shutdown.

OSX is much more forgiving in "impolite" shutdowns than the older Classic OS of years past.

To make sure that the system restarts there should not be any "polite" shutdowns allowed and "restart after power failure" in the System Preferences/Energy Saver/Options should be checked.

To get longer up times in the event of a power failure an RV or Marine battery can be installed in place of the regular battery and will give much longer up times till power is returned. Remember that a UPS is nothing more than a automated power switch that switches from grid power to battery power. Gird tie power inverters for solar panels and wind power do the same thing (but also match the sine wave with the grid when necessary).

Adding the deep cycle RV or Marine battery does void most warranties but has little chance of causing problems. The only consideration is the venting of hydrogen gas that can be explosive in a confined area. As in most situations of modifications you do this of your own accord and assume all liability. Smaller UPS's may not be designed to run for an extended period of time though. You will want to have a look at the heat sinks attached to the output transistors. IN many smaller or short run time models they will be nothing more than a small block of aluminum or a very undersized regular heat sink. These are designed to keep from overheating only for the amount of time that the battery they come with is supposed to run for. If you increase the runtime of these models you run the risk of fire or at least burning it out, or if there is a heat sensor (which many dont have) having it shut down on over temp anyway. Higher end or larger UPS's will often have very large heat sinks and even a fan that will kick in if the temperature gets too high.  So you can't actually purchase a tiny UPS and add a huge battery, but you may be able extend the runtime of a reasonably sized and higher quality one.

====Dealing with X10 switches====
An X10 switch that is set in XTension to "Simulate Preset Dim" doesn't turn on and off, but dims gently to 0 and brightens gently to the setpoint. Sadly the inexpenive X10 switches dont remember their dim setting setting and will come back to life in the "hard off" state. So if XTension attempts to brighten it you'll get the Nova effect of it jumping immediately to 100%. You can walk all your simulate preset dim units though and reset them to the last known state. 

This example makes use of an Attachment script handler called "ResetDimLevel" I use this to dim any lamp regardless of it's state or the state that a user has placed it in back to 0. IN order for the rest of this example to work you will need this in your attachments:

<code AppleScript>
on ResetDimLevel(BadUnit)
	
--first save off what we think is the preset level of the lamp
	set SavedPreset to preset of (BadUnit)

--by dimming it to 100 with no transmit we make XTension think that the next
--step of dimming it to 0 will require the maximum amount of dims
--so no matter what level it's really at due to power failure
--or local contorl it will end up turned off.
	dim (BadUnit) to 100 with no transmit and no script
	dim BadUnit to 0

--and lastly restore the preset level that we want it to go to when it's turned on
	sim preset (BadUnit) to SavedPreset	
	
end ResetDimLevel
</code>

So now the power has failed and been restored, All our simulate preset dim units are in a hard off state, we want to reset them back to the state that XTension thinks they are in. We can get a list of all the preset dim units and walk them and reset their levels something like:


<code applescript>

--this will return a list of all the simulate preset dim units
set MyList to (unit type "simulated")


repeat with MyUnit in MyList


--save off the level that the database THINKS the unit is at
--so we can restore it later	
	set TheLevel to (value of MyUnit)
	
--call the ResetDimLevel for it to make sure it's not in the hard off state
	write log "reset dim level for " & MyUnit
	ResetDimLevel(MyUnit)

--now turn it back on if the database thinks it was before the power failure
--by just turning it on we return it to its preset level
	if TheLevel is greater than 0 then
		turnon MyUnit
	end if
	
end repeat

</code>

====Dealing with Appliance Modules====

The other problem I have during a power failure is a couple of appliance modules that can be guaranteed to come on due to some interaction between local control and the CF bulb plugged into them. One lamp in my living room is 100% reliable to turn on with any power flicker at all. So in addition to managing the simulate preset dim units I also want to walk all my appliance modules and just reset their current state of on or off so that any that changed their state can be reset to how I want them to be. This is slightly more difficult as there is no command to get a list of all appliance modules. I maintain a Group into which I've dragged all the units I wish to process and use that to get the list of units to work with. In the example below the Group is called "all appliance modules"

<code AppleScript>

set MyList to (all of group "all appliance modules")
repeat with MyUnit in MyList
	write log "conform app module " & MyUnit
	if (status of MyUnit) then
		turnon MyUnit
	else
		turnoff MyUnit
	end if
end repeat

</code>

All that does is reset the real state of the module to the known state in the database.

====Dealing with Ninja camera mounts====

Ninja mounts reset to their center position when power is restored, so you may want to send a position command to the ninjas to get them pointing at something interesting again.

====Figuring out that there was a power failure====
With the computer on a UPS it will keep running, but your X10 or other interface must not be on the UPS as they suck signals, so the interface will be powered down. XTension will eventually notice that your interface is not responding and throw a power failure error and execute a global script called "Interface Error Script" But this will likely miss short duration outages. 

If you have a supported UPS the[[supported_hardware:ups|UPS Monitor]]will provide you with quite a bit more data on the power failure and very quick response. You could run your scripts manually of course, but you could also run them in response to the AC POwer unit in the plugin changing state, or the Interface Error script. You may wish to apply some extra logic, or time checking though as you really dont want to reset the dim level, causing a nova effect, for your bedroom overhead light at 2am... or your babies room light at 4am. But you may be able to have a safe list to use during those times, and defer the rest till morning.