EventGhost

I have these two variables taken out from a payload, to control what mode (day, night, no freeze) the heating in a room is set to:
That gives me for instance WC as the Ovnmodusrom and 2 as the Ovnmodus. These are temporary variables which will be destroyed at the end of the script (btw are there local variables in Python like there is in LUA? I tried to search, but didn't find anything about that, and I have a problem finding out how to destroy a variable, but I could of course set it to something that's not relevant). But how do I make those two variables into this variable:
with avalue of 2? So I want the value of the temporary variable Ovnmodusroom to be the _WC part of the resulting variable and the value of the temporary variable Ovnmodus to be the value of this completed variable, in this case the variable eg.globals.Ovnmodus_WC

Remotely understandable again?

Dear Mastiff,
Before posting, to keep the various sections reasonable organized, do first some evaluation in what section you think your topic belongs best. This topic is for sure a thing that would not interest everyone, it is more deep dive into python and others. So the 'Coding Corner' would have been the obvious choice.

Thanks

Yep, sorry. I tried to move it, but found out that you'd already had moved it.

Some admin moved it, thank you!

So your question, as I have understood it, is actually that you would like to create a variable with a name that is dynamically assigned depending on the result of another variable. Why you want to do that, you did not say. Maybe there are better/easier ways if you would describe the next step. I mean, instead of telling you how to swim the Atlantic, I can instead tell you there is an airport around the corner. Provided you are heading to Canada...

But if you are sure, this is the way you can (swim):
This works for standard python variables but not for eg.globals variables. So if you try the next variant you will get an error message. Can you live with this limitation? Why do you need eg.globals?

Thanks! Why eg.globals? Probably because I have almost no idea what I'm doing, I'm just a monkey copying other peoples code much of the time. I actually thought that eg.globals was the only type of variables that could be manipulated this way. I'm probably wrong, what kind of variable should I be using instead?

I do understand some of what I'm doing... The overall reason is that I'm devoting a few months to simplifying my setup as much as possible, with comments and stuff, so somebody else will be able to work it. I'm selling the house as a smarthome next year, and I want everything to be ready within a couple of months so that I can run it one year before I deem it ready for prime time with another administrator! At the moment it's a jumble of a million macros and commands that I hope to simplify a lot. One of the things I'm doing is to change as many regular actions to Python as possible, so instead of having 20-30 actions in a macro (which is the most I have, this is the one that's used to switch the house in away mode and home mode, by turning off all power to all audio-video, going to no frost temp and so on) I'll only have one script which is well commented.

This particular variable manipulation is to avoid having several macros for each room that sets the temperature mode, both in Girder and EventGhost. I am trying to get everything collected in one script, so payloads do the leg work. Girder (where I'm finishing an elaborate system with a webpage for each room, where the occupant can change the day, night and no forst temperatures, when they want the change to take place and their wakeup-call) sends Ovnsmodus (heater mode for Scandinavically challenged readers ) as the event, then WC (yeah, we have occupants there as well...) as the first payload and 1, 2 or 3 as the second payload. I want that to change the associated variable, so in this example the eg.globals.Ovnmodus.WC is given the value in the second payload.

When I have this working I will use exactly the same way to change the temperature in the room by setting a target temperature and then have the oven turn on half a degree above and off half a degree below the target. Most of the rooms are small so I can keep the temp area small. I'm also incorporating the Climate plug-in, but I'm taking one step at a time.

I have experimented a bit with it, and I guess I explained it badly. The problem isn't to set a value of the variable, I want to concatenate the string Ovnmodus_ with the first payload WCso it becomes the name of the variable Ovnmodus_WC which I then give the value in the second payload. Did that help any?

But perhaps that's not possible in Python?

krambriw wrote:Some admin moved it, thank you!

krambriw for EG Forum Admin 2015 !!!

Has a ring to it don't ya think?
You have my vote k

But perhaps that's not possible in Python?

This is possible, that is exactly what I demonstrated with the script samples...

As long as you do it for a normal variable it works. So typically "Ovnmodus_ with the first payload WC" will work fine but "eg.globals.Ovnmodus_ with the first payload WC" will not.

When I try to create a variable in eg.globals this way using vars()[..., I get an error message and the variable is not created. I don't know if this is something that could be said is a bug in EG or if it is just a missing feature never thought of.

That's why I asked you if you could use normal variables for your solution instead of creating them in eg.globals

I would say that you should only define variables in eg.globals if you need to share them among python scripts

Right, then the python scripts work the way I thought (LUA has it the othe way around - all variables are global if you don't mark them Local), because all these variables have to be shared with different scripts. And sorry, I finally found out that I had mixed the variables when I was using the payload test (instead of setting the variables in the script as you have done), and I can get that to work now. Had to change to Testrom so I didn't mess up the running system. So I send the command line:
This is the code that then works:
But you're right, when I try to print eg.globals.Ovnmodus_Testrom instead of Ovnmodus_Testrom I get this error:
So I guess there is no way to convert the local Ovnmodus_Testrom to the eg.globals.Ovnmodus_Testrom, right? The only thing I can think of is to do a re-read of all the variables in that group (heater mode) from the registry, and that's a bit stupid...

You mentioned earlier having one single script....

If you declare your variables at the top level in the script you will have access to them from anywhere in the script, also from functions if you use the keyword 'global', no need to re-read from registry if they are modified by the script itself since you are referencing the same object.

This sample script demonstartes this perfectly: Only problem that could be is of course if you modify the variables in the registry from outside the script. Then you would have to inform the script about this modification somehow. As long as you just READ values from outside, it will not cause any problems.

Yeah, I was a bit unclear. I ment one single script for each thing done. So one script for controlling the heat, one for setting the mode and so on. Sorry. So that mode change is not just to set the registry key, I was going to modify it it's also to change the global variable in the running EG so that the heat controlling script would use the temperature for that mode. I could of course have the heat controlling script re-read the registry value as the first thing it does every time it's run, which is about every minute or so. But would that tax anything in the system, or is it not a problem at all? If not I could have the first line of the heat controlling script use the function that I'm nagging you about to read from the registry. The modification of the registry value would only be done from one script, the rest of the scripts using the registry value would simply read and use it.

So I guess there is no way to convert the local Ovnmodus_Testrom to the eg.globals.Ovnmodus_Testrom, right?

The only way I currently know about would be to pre-define them all at EG start up. I guess your house are pretty much built already and the rooms are known?
You can do this init when your script is starting by putting them at top or put this code in a separate script that runs first. If you do it this way, you can then assign values directly to them, no need to create new variables with dynamically assigned names...

Thanks, but I'm afraid we still talk past each other on this one. Our communication is going so far on the function thing, but here we need dr. Phil! The values are already created, the thing I want to do is to be able to use the first payload to choose the correct "eg.globals.Ovnmodus_" variable to set (in other words use the payload to choose the room) and then set the modus itself with the second payload. But I guess I may just have to use one for each room, I guess with the limitation in global variables it doesn't seem to be possible to do this the way I thought.

Then I have another suggestion, use a global dictionary. You can define a global dictionary holding the statuses of all your rooms. You can easily access them to read or write the value when it changes.
When you receive an event, you extract the payload and then access the related room data

Another one for Sweden, it seems! Thank you very much again! I have made it into something close to what I actually will use. This is the script that's called on startup (not all the rooms yet, and we don't actually have a room called testrom, but you knew that!):
Then here's the script that changes the value (and will be expanded with a function to write it to the registry as soon as that one works, see the other thread ):
And finally an example of the type of query that will be used every time a new temp comes in to that room from the sensor:
That now prints the value that's been sent last from the value setting script through command line! Tackar så mycket!