EventGhost

Latest version: This plugin is intended to assist you to automatically manage your awnings, blinds and/or shutters. It is based on a private plugin I have had in operation successfully since 2011 and now, after this extensive test period, I am confident enough in sharing with others having similar needs.

I personally think that this plugin takes awning management to a higher level than what is normally achieved with the standard wind and rain sensors provided by the manufacturers.

With the plugin you can manage to take a lot of conditions into consideration:

- you can start and end maneuvering based on sunstate, time, season and external sensor readings (light sensor measuring actual sunlight level)
- you can send out synchronization commands so that your awnings/blinds/shutter will return to the correct state in case you or someone did a manual override
- you can control power supply to your motors based on time and season.
- you can still continue to use the standard sensors for wind and rain in parallel

If you combine this plugin with the new RFXtrx433E device you have built-in support for Somfy.
http://www.rfxcom.com/store/Transceivers/14103

For other brands you will have to find the specific way to communicate with your devices. Myself I have ELERO and I used a simple remote control and some other electronics to build a USB connected device.

Why have power supplied to the motors all year if you only use them during the summer season? You better check if your devices keeps the programming if powered off for a longer period. In the ELERO case, this is not a problem. I turn off the power when the summer season ends and then on again next spring. It works perfect and I save a few watt hours.

For the sunstate and weather conditions, this plugin also requires the SunTracker plugin to be installed.

The various weather conditions and the classification is kept in a separate file in the plugin folder This file is easy to edit if you need that (weather_conditions_abs.py)

To capture sensor readings and, as mentioned above, to send maneuvers, suitable plugins like the RFXtrx plugin, are also required.

In the following I will describe how you can use it and the various settings needed.

This is the basic plugin and its settings and the example is my own. The plugin can handle several so called Control actions. Each Control action has its own settings and all are using the common plugin settings. All running Controls are listed in the list box. This allows you to manage various awnings, blinds and shutters with different settings, all depending on your local house architecture, conditions and placements.
"Summer Season Begins with (month): " Here you simply select the month of the year when you would like to start enabling the automation

"Summer Season Ends with (month): " Select the month when automation shall be disabled again

"Consider seasonal settings: " Check box to enable seasonal settings, unchecked it will be enabled the whole year

"Set sensor average threshold level: " Use for your specific light sensor and set the threshold at the suitable level when you normally would like a change of maneuvering

"Sensor data samples for END calculation: " Set the number of readings to be used for the average END calculation

"Sensor data samples for START calculation: " Set the number of readings to be used for the average START calculation

A remark to this is that you would normally like to have a faster START and a slower END calculation to avoid awnings to move up and down too quickly for shorter temporary light level changes due to smaller clouds passing by.

This is the Control action and its settings. This example is my own used to manage awnings placed on the south/east side of our house. We basically need those awnings sunny days from the morning until 13.00 in the afternoon.
"Controler name: " Just give it a describing name

"START Event name: " Name the event with a good describing name and then use it in your macros

"END event name: " Name the event with a good describing name and then use it in your macros

"Day START" Here you have a number of fields for setting time settings. The typical format is a 24 hour clock, like 0630, 1400, 2200 etc

"Print loop and debug info: " Use this to debug if something is not working correctly or in the beginning, if you want to check that everything works ok

"Log activities to file: " As it says, if you like to have the maneuvering commands also in a log file

"Synchronization activated: " If you want to synchronize the devices (as described earlier)

"Synchronization interval (6-600 min): " The synchronization interval

"Consider weather conditions: " Check if the this Control action shall consider the wheather or not (for normal awnings/blinds/shutter management you would typically check this box. For seasonal power control to motors you would not)

"Use for maneuvering: " Only check when the Control action is for maneuvering of the awnings/blinds/shutters

"Select the offset related to sunrise: " You can select a offset for the maneuver to delay it after the sunrise. I use a delayed maneuver myself because some large trees are giving shade the first 2 hours after sunrise.

"Select the offset related to sunset: " Same reason for this setting, you can select a offset for the maneuver to start it before the sunset.

This example is my own for a Control action that I use to control seasonal power supply to the motors and transceiver electronics built into the awnings.
The power is only ON from 05.00 in the morning until 17.00 in the afternoon during the brighter part of the season (from March until September).

This is the description of the action to capture light sensor readings from a RFXtrx device and calculate the average values used by the logic determining when the maneuver shall START or END.

A first note is of course that you have to have a suitable sensor. I have modified an Oregon sensor according to a description you can find at the link below (unfortunately only in Swedish but the pictures and schematics will give you ideas how to do it. If you run into problems understanding I will try to assist you): http://www.switchking.se/forum/viewtopic.php?f=8&t=450

An exception I took was that I replaced the humidity sensor instead of the temperature sensor to get readings in percentage. The Oregon sensor will normally send you a new reading every 45-50 seconds so therefore an average calculation is necessary and made every time new data arrives. With my modification, the normal threshold level (configured in the plugin settings) is around 81 and I have selected a hysteresis of -1.0 to avoid that the awnings are moving up/down frequently when the average light levels are jumping closely around the threshold level.
Here are explanations of the settings:
"Give the sensor a name: " Well, name it

"Select the payload position of the value: " Here you insert the position in the payload that holds the value. Remember counting starts from zero

"Enter the device ID of the sensor: " Insert the device id of the sensor, it is visible in the event string and you can copy paste it from there

"Select the hysteresis between START and END commands: " As mentioned, select a reasonable hysteresis to reduce sensitivity around the threshold level

"Select or enter the number of seconds for sensor lost event: " This setting is for the monitoring of communication with the device. If no message is received within the specified time, an event will be generated in EG that you can use, eventually to push a notification to your smartphone

My example above is based on my Oregon sensor that typically report events via the RFXtrx like this one:
The sensor id is 51460, the humidity 78% is actually the current outdoor light level in the late afternoon and the value is found in position 6 of the payload (if we split the payload string with ÔÇÿ ÔÇÿ into a list).

Once you have configured the action and created a macro for it, you can just drag the event from your sensor to the same and the collection of data will start.

This is the description of the action to capture light sensor readings from other devices like OneWire sensors. Also in this case, the logic calculates average values used when the maneuver shall START or END.

As mentioned above you have to have a suitable sensor. I have based this example on a OneWire sensor looking like this one: The OneWire sensor gives me a new reading every 60 seconds so therefore an average calculation is necessary and made every time new data arrives. With my modification, the normal threshold level (configured in the plugin settings) is around 81 and I have selected a hysteresis of -1.0 to avoid that the awnings are moving up/down frequently when the average light levels are jumping closely around the threshold level.
Here are explanations of the settings:
"Give the sensor a name: " Well, name it

"Enter the key for the device ID: " Here you insert the keyword that can be used to extract the device ID

"Enter the device ID of the sensor: " Insert the device id of the sensor

"Select the hysteresis between START and END commands: " As mentioned, select a reasonable hysteresis to reduce sensitivity around the threshold level

"Select the base value the reading shall be added to: " Depending on the signal value you receive, it might be necessary to add a base level value (I use 60.0 as base level)

"Select the multiplier for the read value: " Depending on the signal value you receive, it might be necessary to use a multiplier to increase the value (I use 10.0 as multiplier)

"Select or enter the number of seconds for sensor lost event: " This setting is for the monitoring of communication with the device. If no message is received within the specified time, an event will be generated in EG that you can use, eventually to push a notification to your smartphone

The example above is based on my OneWire sensor that typically report events looking like this one:
The key for the device ID is ÔÇÿsensorIdÔÇÖ, the sensor id is ÔÇÿ20.09F40C000000/volt.BÔÇÖ, the key for the value is 'lightlevel' and the actual reported light value this late afternoon is '1.14072'. With the base level value and multiplier, the result is ÔÇÿ71.4072ÔÇÖ. This has proved to be perfect with a configured threshold of 81.0

I hope you have use for this plugin in the same way I have. It is really nice when automation is seamless working in the background, almost like reading your intentions up front.

Best regards, Walter

I overlooked some use cases that do not work correctly. Back to work bench...

BestR

I think I started this topic a bit too optimistic but now, after almost 1 month of extensive testing, I think it works perfect and it is fully automating my awnings. See the first post

Best regards, Walter

Walter,

This is awesome! I don't have any automatic awnings yet, but maybe this will entice me to get some.

Thanks for sharing!

Hi, this seems like a really great plugin!

Is there any way to get it to workt together with some sort of wind sensor?

Hello,
Currently there is no support for wind conditions. When I designed it, I thought my original wind sensor delivered together with the awnings (brand is Elero) was a good fail safe in itself. It would not be as critical if you get some rain on them as compared to if they are blown away by a strong wind...

Anyway, everything is possible if we can capture the signal from your wind sensor. I think I could for instance create a new action that evaluates the wind strength and direction and compares this to rules when awnings should be send up.

What kind of wind sensor and receiver do you have? Do you see the wind sensor events in the log already today?