Some days ago, I asked for help to stop my rollershutter, when the door contact is open.
I got good help from the community and hope, that is will be the same for this issue.
Trying to realise, that the rollershutter is going down, at the moment the temperature measured at the radiator controller is above a certain threshold.
With the rollershutter and the door contact, it was ‘quite easy’, as it is a 1:1 relation. Today I have a 1:n relation.
Which means, that the items triggered by val windowName = nameParts.get(0) + “_” + nameParts.get(1) + “ht” + nameParts.get(3) + “_act_temp” does not match with the filter
It has something to do, that I create a new value out of my rollershutter and try to match this with the name of the radiator controller.
I.e the item OG1_sz_rs_tuer creates in my rule the name OG1_sz_ht_tuer, but this name does not exist as an item. Therefore the rule fails. If I use only rollershutter, which have a 1:1 relation to radio controller, the rule works perfectly.
Therefore I look for something, as a wildcard, where I could say, create from item OG1_sz_rs_tuer a value like OG1_sz_ht_* (*=wildcard) Then for all the rollershutter in the sleeping room the temperature would be looked up at the radiator controller OG1_sz_ht_fenster_act_temp.
Changing the windowName into a Global variable, does not help - as said, I need something like a wildcard, which I could use in general.
@Markus: Thanks for the post you mentioned, but this is exactly, what I don’t want. If I follow your post I need to specify an action for each window separately - we have +20 windows, where I think it isn’t practicable.
There is already a logInfo in for each single line.
It fails at the moment, when it compares the name of the rollershutter with the radiator controller:
10:45:07.435 [INFO ] [smarthome.event.ItemStateChangedEvent] - EG_wz_switch_3_long_test changed from OFF to ON
10:45:14.991 [INFO ] [.eclipse.smarthome.model.script.DEBUG] - Hitzeprüfung startet
10:45:15.521 [INFO ] [.eclipse.smarthome.model.script.DEBUG] - windowname = OG1_sz_ht_tuer_act_temp
10:45:15.671 [INFO ] [smarthome.event.ItemStateChangedEvent] - EG_wz_switch_3_long_test changed from ON to OFF
10:45:16.150 [ERROR] [untime.internal.engine.RuleEngineImpl] - Rule 'Sommerhitze draussen lassen Test': cannot invoke method public abstract org.eclipse.smarthome.core.types.State org.eclipse.smarthome.core.items.Item.getState() on null
```
I understand what you are trying to do
You want 1 temperature controller for 2 rollershutters in this case above
Rename OG1_sz_ht_fenster_act_temp to OG1_sz_act_temp
Change windowName to: windowName = namePart.get(0) + "_" + nameParts.get(1) + "_act_temp"
For each rs the result will be compared against the same temperature
What threw me is the name windowName, it’s not a window, it’s a temperature sensor
A little bit of change in your naming convention and maybe change windowName to tempSensor for clarity
Exactly, one temp sensor controls min. 2 rollershutters.
But the thing is, that I have several room, where I have two or more temp sensors (ie. living room). Therefore renaming the radiator controller is not the perfect way to fix it.
Agree with you about the windowName. Will change it.
I have two different rules for those kind of topics. One which runs every minute and determines some states like temp differences and sets a status in a global item (e.g.LivingWindow1 (1 shall go down, 2 shall go up)).
Then second more room individual where I compare and then based on global status.
Makes it easier to read and maintain when coming back in 1 year and wondering what I wanted to achieve
Yes, but each windows are driven by one off them, If you work on your Item naming carefully by matching the temp controller to the windows it is driving then you’ll achieve your goal
I played a bit around and lucky me, I was able to archive the requested function w/o altering all the item names.
If someone is interested in the same solution, please find my final code underneath:
rule "Sommerhitze draussen lassen Test"
when
Item EG_wz_switch_3_long_test received update OFF
//Item Temperature changed
then
if (Temperature.state > 10){
if (Season.state == ON){
logInfo("DEBUG", "Hitzeprüfung startet")
gH_Rolladen.allMembers.forEach[rs|
var nameParts = rs.name.split("_")
val tempName = nameParts.get(0) + "_" + nameParts.get(1) + "_ht_"
logInfo("DEBUG", "tempName = " + tempName)
if (gH_Temperature?.allMembers.filter [fk | fk.name.startsWith(tempName)].head.state > 23){
logInfo("DEBUG", "Zimmer " + tempName + " is too hot!")
if (rs.state != 100)
{
postUpdate(rs,DOWN)
logInfo("DEBUG", "Fahre runter")
//sendCommand(rs,80)
}
}
else {
logInfo("DEBUG", "Zimmer " + tempName + " ist noch angenehm warm!")
}]
}
}
else {
logInfo("DEBUG", "Noch nicht warm genug für Zimmertemp.-Check")
}
end
I just restart this threat, as it perfectly describes my setup.
The code, which I showed in April works perfectly for me, except, that the WAF is not fulfilled:
My wife would like to have a code, which checks, if the rollershutter was moved up, after closed for shading.
In this case, it should not move again at the next event -> should prevent, that she i.e. moves the rollershutter up to enjoy the sun and it closes after some minutes again.
Put some brain in and came to the conclusion, that a variable (i.e. windowindex) which is set to1 within the first if-clause could solve the issue. Every night I would set it to 0 with a cron job.
But as easy, as I drafted in example above with windowindex it isn’t. The variable windowindex need to apply per window, means somehow I need to get the windowName in into the variable name.
Any ideas how I could realize it? I think then the WAF would be met and I could relax within the summer.
This is the part I haven‘t implemented yet. In principle I think what I need to do. My shading positions are never 100% closed. So I could check before I move via rule if a) the last movement was during sunrise (timestamp) and b) it is at 0% to go into sun position or in case the automatic will move up if it is at 78% or whatever the shading position is.
So if a user decides to stop the movement, it will be somewhere in between. Also if it was moved down before. The odds that it is at 78% is quite limited and can live with that.
