Is it possible to import in an embedded python script?

I have a script that is being run whenever a z-wave event occurs on a thermostat. The script monitors the actual temperature and heat setpoint of the thermostat and if necessary turns on the boiler to provide heat. As this will be happening for at least ten thermostats, I have devised a system that maintains a count of the number of thermostats calling for heat. If this count is greater than zero the boiler is turned on otherwise off.

I think I need to run this trigger script synchronously - it should be very quick to run. As I understand it this will be achieved by running it as an embedded script. To avoid replicating the script across ten thermostats I could run it as a file. However, if I do this it runs in its own thread and in theory you could get confusing updates to the common count of radiators calling for heat if the script was fired at similar times and multiple threads were running.

This background info (as way of explanation) is a long way round asking whether it is possible to run an include statement in an embedded script so that I don't have to replicate the majority of the script code

[matt (support)]

I've got an idea that might help. Inside the individual Triggers you are defining for each thermostat instead of having it execute an embedded script have it perform the Modify Variable Value action where the variable target is a new one you create called "ThermostatTarget" and the value is whatever thermostat name or device ID is being used by the Trigger.

Next create a single Trigger action of type Variable Value Changed. Its action will then be the embedded script. The script should then retrieve the variable value for your ThermostatTarget variable, which it can then use to know what device target it is processing.

So the net result is you'll have an individual Trigger for each thermostat which does nothing but set ThermostatTarget, which then causes the real Trigger to execute while at the same time allowing you to pass the device ID (or name, but ID preferred) into the script indirectly.

I've got an idea that might help. ...

Thanks for the suggestion - I'll give it a go

I have done the change and it works OK testing with one thermostat, which is all I have at the moment.

I am just wondering about the sequencing of the triggers.

At the moment, the following happens:
- zwave event for thermostat 01 activates trigger to set the variable to '01'
- variable change activates trigger to run main script which uses variable set to '01' to determine which thermostat to process.

However, in the future when I have many more thermostats can I rely on the these two triggers running one after the other in a multi-thermostat scenario or could they get out of step

For example:
- zwave event for thermostat 01 activates trigger to set the variable to '01'
- variable change activates trigger to run main script which uses variable set to '01' to determine which thermostat to process.
- zwave event for thermostat 02 activates trigger to set the variable to '02'
- variable change activates trigger to run main script which uses variable set to '02' to determine which thermostat to process.
- zwave event for thermostat 03 activates trigger to set the variable to '03'
- zwave event for thermostat 04 activates trigger to set the variable to '04'
- variable change activates trigger to run main script which uses variable set to '04' to determine which thermostat to process.
- variable change activates trigger to run main script which uses variable set to '04' to determine which thermostat to process.

In this example thermostat '03' wouldn't get processed. It would correct itself at the next 5 minute wake-up unless it again got subverted by another z-wave event.

[matt (support)]

In that example I believe thermostat 03 would be skipped but the triggering will probably happen fast enough that is doesn't occur ever/often. If 3 were to happen in a row the likelihood of a skipped thermostat increases. Presuming 03, 04, and 05 happen fast enough that the script is still processing the logic/commands for 03 when 04 and 05 come in then you would have:

- zwave event for thermostat 03 activates trigger to set the variable to '03'
- variable change activates trigger to run main script which uses variable set to '03' to determine which thermostat to process.
- script starts processing 03
- zwave event for thermostat 04 activates trigger to set the variable to '04'
- zwave event for thermostat 05 activates trigger to set the variable to '05'
- script completes processing 03
- variable change activates trigger to run main script which uses variable set to '05' to determine which thermostat to process.
- script starts processing 05 (04 skipped)

If it turns out to be a problem, then you could use a comma separate list as a queue. So the logic of the embedded script would be to read out the variable value, if it is non-empty then remove the first number from the comma list and process that device then at the end of the script put back into the variable value the updated device ID list (or empty string of processing is done).

[jay (support)]

Seems like you're making this much more complicated than it needs to be: if your goal is just to make sure that the boiler is running whenever any thermostat is calling for heat that is. As I pointed out in another post this would be pretty darn simple in a plugin, but even using a script and variable it's really pretty simple - increment a variable when it needs the boiler to be on, decrement when it doesn't. When the variable becomes greater than 0 turn it on, when it becomes 0 turn it off.

What am I missing?

... What am I missing?

You are essentially correct in what my script does.

I was trying to avoid having to replicate the script 10+ times and I want it to run synchronously so that the counter can't be changed during the duration of the script. I know this is unlikely but not impossible as the 10+ thermostats will be waking up every 5 minutes. In addition I don't think I can rely on the thermostat switching completely off when the Heat Setpoint is reached hence getting the script to set the thermostat Heat Setpoint low when this occurs (See this post in the Stella-Z thread)

As previously mentioned, if the trigger name could be accessed by the script or you could pass a parameter to the script there wouldn't be an issue. Matt was just suggesting a way around this.

Yes, it may be over complicated but I was trying to cover all bases

[jay (support)]

No need to replicate the script - just run it for each trigger. I'm not sure why you'd need to to be synchronous - but if you do then making this thing a plugin is definitely the way to go. Your plugin's execution can totally control what it's doing and when so you won't need all these tricks to try to make Indigo actions (which are inherently asynchronous) perform synchronously.

No tricks, hacks, or holding your mouth right while processing.

... making this thing a plugin is definitely the way to go. ...

I am going to give it a go and see what happens