That’s what I’m hoping. I was trying to do some learning with groups and I think I jumped in too quickly so missed something simple along the way.
I’ll try again in the morning and see what happens. If it still doesn’t work then you’ll all probably hear the scream from wherever in the world you are…
Ok, deleted all items, groups, rules etc associated with this thread, restarted, (just for fun), and started again…
ITEMS
2 dimmer items and a dummy item to use as a switch to test:
Dimmer GF_LR_HueLight1_Brightness "GF LR Spotlight 1 Dimmer" <light> {channel="hue:blah:brightness"}
Dimmer GF_LR_HueLight1_ColorTemp "GF LR Spotlight 1 Color" <light> {channel="hue:blah:color_temperature"}
Switch vLivingRoomSpots "LR Spot Test"
BASIC RULE TO TEST
Step 1 - Start with ON/OFF to a dimmer item
rule "Living Room Spotlights"
when
Item vLivingRoomSpots received command
then
if(vLivingRoomSpots.state == ON)
{
logInfo(logName,"Living Room Spots Test ON")
GF_LR_HueLight1_Brightness.sendCommand(ON)
}
else
{
logInfo(logName,"Living Room Spots Test OFF")
GF_LR_HueLight1_Brightness.sendCommand(OFF)
}
end
LOG
Turning vLivingRoomSpots ON via sitemap switch
2020-04-26 11:06:56.582 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 11:06:56.597 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 11:06:56.617 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command ON
2020-04-26 11:06:56.649 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become ON
2020-04-26 11:06:56.676 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 0 to 100
Turning vLivingRoomSpots OFF via sitemap switch
2020-04-26 11:07:06.303 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command OFF
2020-04-26 11:07:06.317 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from ON to OFF
2020-04-26 11:07:06.331 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command OFF
2020-04-26 11:07:06.356 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become OFF
2020-04-26 11:07:06.374 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 100 to 0
So, all looks good there…however…the physical light turned ON fine, (hooray), however it is still on, regardless of the clear OFF command in the logs.
So, thinking about the rule I realised that using the received command trigger, the Rule will trigger before the Item’s state is updated so it wouldn’t turn off anyway…(correct???)
I changed the rule to ‘received update’ and ‘changed’ just to see what would happen and the light didn’t turn on or off, the logs were also a bit jumbled eg
LOG
2020-04-26 11:14:13.084 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 11:14:13.112 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 11:14:15.684 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command ON
2020-04-26 11:14:15.701 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become 0
So in this case, it ran through the rule, turned the spot ON, but brightness was 0? ie it’s OFF…not what I want either…
Next Step -
I modified the rule so that if vLivingRoomSpots received command as before but it now checks to see if receivedCommand ==ON to correct the received command when:
rule "Living Room Spotlights"
when
Item vLivingRoomSpots received command
then
if(receivedCommand == ON)
{
logInfo(logName,"Living Room Spots Test ON")
GF_LR_HueLight1_Brightness.sendCommand(ON)
}
else
{
logInfo(logName,"Living Room Spots Test OFF")
GF_LR_HueLight1_Brightness.sendCommand(OFF)
}
end
But this got even more confusing, the physical light neither came on or off and the logs showed this:
2020-04-26 11:27:27.535 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 11:27:27.554 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 11:27:27.559 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command ON
2020-04-26 11:27:27.580 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become 0
2020-04-26 11:27:29.908 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 0 to 100
2020-04-26 11:27:30.466 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command OFF
2020-04-26 11:27:30.538 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command OFF
2020-04-26 11:27:30.564 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become 100
2020-04-26 11:27:30.566 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from ON to OFF
2020-04-26 11:27:39.936 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 100 to 0
All sorts of fun going on there! ON predicting to become 0, (ie off), and the OFF predicted to become 100, (ie ON)…
So, any ideas what is going on here? I’m goiong to go away and change the commands to sending 0 / 100 rather than on / off and see if that makes a difference…next post shortly…
So, next part of the saga
Changed the rule to:
rule "Living Room Spotlights"
when
Item vLivingRoomSpots changed
then
if(vLivingRoomSpots.state == ON)
{
logInfo(logName,"Living Room Spots Test ON")
GF_LR_HueLight1_Brightness.sendCommand("100")
}
else
{
logInfo(logName,"Living Room Spots Test OFF")
GF_LR_HueLight1_Brightness.sendCommand("0")
}
end
Gives the logs
SWITCH ON
2020-04-26 11:36:28.083 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 11:36:28.100 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 11:36:28.117 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command 100
2020-04-26 11:36:28.143 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become 100
2020-04-26 11:36:28.154 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 0 to 100
SWITCH OFF
2020-04-26 11:36:29.739 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command OFF
2020-04-26 11:36:29.750 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from ON to OFF
2020-04-26 11:36:29.763 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command 0
2020-04-26 11:36:29.786 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become 0
2020-04-26 11:36:29.805 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 100 to 0
Also, the light turned on and off properly…
The only thing of note here is that the first ON/OFF command I gave it from the sitemap switch didn’t work:
2020-04-26 11:36:13.581 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 11:36:13.593 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 11:36:15.089 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command OFF
2020-04-26 11:36:15.098 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from ON to OFF
2020-04-26 11:36:16.112 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command 0
2020-04-26 11:36:16.133 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command 0
2020-04-26 11:36:16.160 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become 0
2020-04-26 11:36:16.174 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become 0
So you can see it got a little jumbled, and the light didn’t turn on or off, it did work on the second on / off. I’m guessing I therefore need to capture the current state before I do anything to make sure it works???
Also, I’m guessing that the hue ambience bulb doesn’t accept ON/OFF commands just 0/100 brightness commands???
Any comments / thoughts before I plough on with these thoughts and start to add more bulbs and begin my groups journey? I’d rather start off knowing exactly how the bulb works so I can code accordingly…
Yes, for the trigger. Whether the state has been updated before you examine it within the rule is indeterminate - it’s a “race condition”, because we are in a multithreading system.
Don’t know, you’ve only shown us the prediction not any actual state change. Remember predictions can be overridden by bindings,
Is this Item GF_LR_HueLight1_Brightness linked to some real hue channel? Or is the hue binding saying, nope that’s a nonsense channel, it’s broken, commands won’t have effect. It’s not clear if there is a real lamp involved here, because you show us a fake channel.
Entirely possible. The hue binding docs are not clear, and it may in any case vary by device model.
The openHAB idealized Dimmer type Item accepts ON/OFF commands, which get passed via channel to binding. What happens about them then is up to the binding - ignore, pass to device, translate to something else.
I’d sort this out before you involve Groups.
Great, thanks for the clarification…glad some of the learning is staying in my head 
That is all the logs showed, nothing more, it only predicted to change, it didn’t actually change…
GF_LR_HueLight1_Brightness is a real item, it is linked to a real hue channel, Paper UI image:
The item works when I send it
GF_LR_HueLight1_Brightness.sendCommand("100")
Which says to me it is a working / linked item?
I agree, I think from my testings the hue bulb doesn’t like ON/OFF but 0 / 100 seems fine…as long as this is correct I now know what ball park I’m playing on so can continue testing from there.
I do wonder if the hue app is also trying to connect / modify the blub which might be interfering, but having said that my old hue bulb works fine…
Thanks all for the help to date.
Remember we cannot see you what you see, and that kind of phrase is open to interpretation. In openHAB, an Item is a conceptual object with no reality. Somewhere you’ve got a physical light bulb associated with that.
You know what you mean, but we cannot tell if “item works” means the physical light bulb comes on.
There is some stuff about hue and ON/OFF here
Someone there seems to have hue type 220 responding to ON/OFF not on the brightness but the colortemperature channel.
Yes, it’s hard to describe virtual and physical items, especially when I’m not sure what is and isn’t working!
Never thought of using the color temp channel, I’ll give that a go. It says it is a dimmer on Paper UI so seems to be the same in principle as the brightness channel but I’ll give anything a go right now to see if it works!!!
HI,
In the interest of keeping this thread going in case someone else has the same issue…
I have now tried the rule using the colortemp channel.
rule "Living Room Spotlights"
when
Item vLivingRoomSpots changed
then
if(vLivingRoomSpots.state == ON)
{
logInfo(logName,"Living Room Spots Test ON")
GF_LR_HueLight1_ColorTemp.sendCommand(ON)
}
else
{
logInfo(logName,"Living Room Spots Test OFF")
GF_LR_HueLight1_ColorTemp.sendCommand(OFF)
}
end
So, this turns the physical light on and off when I switch vLivingRoomSpots on / off so that’s a good start…however it was a very dull light…
Looking at the logs:
ON:
2020-04-26 20:04:43.702 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 20:04:43.709 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 20:04:43.720 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_ColorTemp' received command ON
2020-04-26 20:04:43.736 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_ColorTemp predicted to become ON
2020-04-26 20:04:43.750 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_ColorTemp changed from 0 to 100
2020-04-26 20:04:44.011 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_ColorTemp changed from 100 to 23
2020-04-26 20:04:44.013 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 0 to 1
OFF:
2020-04-26 20:04:45.356 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command OFF
2020-04-26 20:04:45.383 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from ON to OFF
2020-04-26 20:04:45.388 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_ColorTemp' received command OFF
2020-04-26 20:04:45.421 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_ColorTemp predicted to become OFF
2020-04-26 20:04:45.435 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_ColorTemp changed from 23 to 0
So, it seems that this channel can receive ON/OFF commands but that it is independent of the brightness channel, (as you’d expect I suppose).
ColorTemp = 23 is what it was set to the last time the physical light was on so it has reverted to the ‘last known setting’. Interestingly, it seems to have set it to 100 and then back down to 23 so I wonder if there is some hue app trickery taking over / getting involved here or if the bulb does actually remember it’s ‘last on state’ somehow.
I went into the hue app and changed the color temp to 80, (random number, ie not 23), and brightness to 52, then turned vLivingRoomLights ON and OFF again…
Log
ON
2020-04-26 20:16:31.826 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 20:16:31.837 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 20:16:31.862 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_ColorTemp' received command ON
2020-04-26 20:16:31.887 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_ColorTemp predicted to become ON
2020-04-26 20:16:31.906 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_ColorTemp changed from 0 to 80
OFF
2020-04-26 20:16:34.652 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command OFF
2020-04-26 20:16:34.665 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from ON to OFF
2020-04-26 20:16:34.686 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_ColorTemp' received command OFF
2020-04-26 20:16:34.711 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_ColorTemp predicted to become OFF
2020-04-26 20:16:34.728 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_ColorTemp changed from 100 to 0
2020-04-26 20:16:35.384 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_ColorTemp changed from 0 to 80
2020-04-26 20:16:35.386 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 52 to 0
So,yes…it would seem that it remembers the last ON setting…or the hue app is taking over…
Either way, I think I now know / understand why the ON/OFF command is temperamental…the bulb requires 0 / 100 in both brightness and color temp, (either together or individually), to set the temp you want it to be as ON/OFF will simply take you to the ‘last known setting’ of the bulb.
Does that seem a sensible suggestion?
NOTE - I have noticed there can be a few second delay between sending the command on OH and the physical bulb turning on. Sometimes its instant, other times it could be up to 3 seconds delay…might be useful to note when running rules…
Remember the “it” here is the Item model dimmer internal to openHAB.
When you see the Item state change to 100, in events.log, it does not mean the device had anything to do with it.
autoupdate is at work when you send commands (unless you disable autoupdate) - this is the source of the “prediction” … and the update to 100 within a few milliseconds. It’s a guessed, predictive, pre-emptive update, and does not reflect any real world value.
Later on, after the command has chuntered around the huw network, the bulb has done its thing, the response chuntered back … the “real” status is applied to the Item, a quarter-second later.
EDIT, meant to say also
it’s a recognized effect when running a rule for the very first time after loading
(editing) due to compilation. It’ll be noticeable on a busy Pi.
Ah, that makes sense…
Right, next step:
I now have 2 lights:
Dimmer GF_LR_HueLight1_Brightness "GF LR Spotlight 1 Dimmer" <light> (gLivingRoomLights) {channel="hue:0220:00178877b4a1:5:brightness"}
Dimmer GF_LR_HueLight1_ColorTemp "GF LR Spotlight 1 Color" <light> {channel="hue:0220:00178877b4a1:5:color_temperature"}
Dimmer GF_LR_HueLight2_Brightness "GF LR Spotlight 2 Dimmer" <light> (gLivingRoomLights) {channel="hue:0220:00178877b4a1:6:brightness"}
Dimmer GF_LR_HueLight2_ColorTemp "GF LR Spotlight 2 Color" <light> {channel="hue:0220:00178877b4a1:6:color_temperature"}
A group:
Group gLivingRoomLights "Living Room Lights" <light>
A rule:
rule "Living Room Spotlights"
when
Item vLivingRoomSpots changed
then
if(vLivingRoomSpots.state == ON)
{
logInfo(logName,"Living Room Spots Test ON")
gLivingRoomLights.sendCommand("100")
//GF_LR_HueLight1_Brightness.sendCommand("100")
//GF_LR_HueLight2_Brightness.sendCommand("100")
}
else
{
logInfo(logName,"Living Room Spots Test OFF")
gLivingRoomLights.sendCommand("0")
//GF_LR_HueLight1_Brightness.sendCommand("0")
//GF_LR_HueLight2_Brightness.sendCommand("0")
}
end
If I run the rule with the commented lines, ie sendCommand(“100”) to each spot independently, then everything is fine, spotlight comes on.
If I run the rule with the gLivingRoomLights.sendCommand(“100”) then the physical lights don’t come on…
Log
2020-04-26 20:39:14.760 [INFO ] [clipse.smarthome.model.script.lights] - Living Room Spots Test ON
2020-04-26 20:39:14.769 [WARN ] [rthome.model.script.actions.BusEvent] - Cannot convert '100' to a command type which item 'gLivingRoomLights' accepts: [].
What am I missing?
I think you need to give the Group a type
Group:Dimmer gLivingRoomLights "Living Room Lights" <light>
I always thought it didn’t care, but I could reproduce your error myself. Maybe validation got stricter.
Unrelated - Strictly, you should be commanding Dimmers with a number, not a string
gLivingRoomLights.sendCommand(100)
Great, getting somewhere I think now…Half the battle seems to be understanding how these lights work, and that they are different from the other hue bulbs it would seem!
So,
All 4 spots as items now:
Dimmer GF_LR_HueLight1_Brightness "GF LR Spotlight 1 Dimmer" <light> (gLights_LR) {channel="hue:0220:00178877b4a1:5:brightness"}
Dimmer GF_LR_HueLight1_ColorTemp "GF LR Spotlight 1 Color" <light> (gLights_LR_ColorTemp) {channel="hue:0220:00178877b4a1:5:color_temperature"}
Dimmer GF_LR_HueLight2_Brightness "GF LR Spotlight 2 Dimmer" <light> (gLights_LR) {channel="hue:0220:00178877b4a1:6:brightness"}
Dimmer GF_LR_HueLight2_ColorTemp "GF LR Spotlight 2 Color" <light> (gLights_LR_ColorTemp) {channel="hue:0220:00178877b4a1:6:color_temperature"}
Dimmer GF_LR_HueLight3_Brightness "GF LR Spotlight 3 Dimmer" <light> (gLights_LR) {channel="hue:0220:00178877b4a1:7:brightness"}
Dimmer GF_LR_HueLight3_ColorTemp "GF LR Spotlight 3 Color" <light> (gLights_LR_ColorTemp) {channel="hue:0220:00178877b4a1:7:color_temperature"}
Dimmer GF_LR_HueLight4_Brightness "GF LR Spotlight 4 Dimmer" <light> (gLights_LR) {channel="hue:0220:00178877b4a1:8:brightness"}
Dimmer GF_LR_HueLight4_ColorTemp "GF LR Spotlight 4 Color" <light> (gLights_LR_ColorTemp) {channel="hue:0220:00178877b4a1:8:color_temperature"}
2 Groups, one brightness and the other color temp:
Group:Dimmer gLights_LR "Living Room Lights" <light>
Group:Dimmer gLights_LR_ColorTemp "Living Room Lights ColorTemp" <light>
One rule:
rule "Living Room Spotlights"
when
Item vLivingRoomSpots changed
then
if(vLivingRoomSpots.state == ON)
{
logInfo(logName,"Living Room Spots Test ON")
GF_LR_HueLight1_Brightness.sendCommand("100")
GF_LR_HueLight1_ColorTemp.sendCommand("14")
GF_LR_HueLight2_Brightness.sendCommand("100")
GF_LR_HueLight2_ColorTemp.sendCommand("14")
GF_LR_HueLight3_Brightness.sendCommand("100")
GF_LR_HueLight3_ColorTemp.sendCommand("14")
GF_LR_HueLight4_Brightness.sendCommand("100")
GF_LR_HueLight4_ColorTemp.sendCommand("14")
}
else
{
logInfo(logName,"Living Room Spots Test OFF")
GF_LR_HueLight1_Brightness.sendCommand("0")
GF_LR_HueLight2_Brightness.sendCommand("0")
GF_LR_HueLight3_Brightness.sendCommand("0")
GF_LR_HueLight4_Brightness.sendCommand("0")
}
end
LOG:
2020-04-26 22:35:46.947 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 22:35:46.962 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 22:35:46.978 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_Brightness' received command 100
2020-04-26 22:35:47.009 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight1_ColorTemp' received command 14
2020-04-26 22:35:47.029 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight2_Brightness' received command 100
2020-04-26 22:35:47.045 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight2_ColorTemp' received command 14
2020-04-26 22:35:47.060 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_Brightness predicted to become 100
2020-04-26 22:35:47.064 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight3_Brightness' received command 100
2020-04-26 22:35:47.102 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight3_ColorTemp' received command 14
2020-04-26 22:35:47.118 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight4_Brightness' received command 100
2020-04-26 22:35:47.134 [ome.event.ItemCommandEvent] - Item 'GF_LR_HueLight4_ColorTemp' received command 14
2020-04-26 22:35:47.149 [nt.ItemStatePredictedEvent] - GF_LR_HueLight1_ColorTemp predicted to become 14
2020-04-26 22:35:47.163 [nt.ItemStatePredictedEvent] - GF_LR_HueLight2_Brightness predicted to become 100
2020-04-26 22:35:47.174 [nt.ItemStatePredictedEvent] - GF_LR_HueLight2_ColorTemp predicted to become 14
2020-04-26 22:35:47.185 [nt.ItemStatePredictedEvent] - GF_LR_HueLight3_Brightness predicted to become 100
2020-04-26 22:35:47.195 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_Brightness changed from 0 to 100
2020-04-26 22:35:47.200 [nt.ItemStatePredictedEvent] - GF_LR_HueLight3_ColorTemp predicted to become 14
2020-04-26 22:35:47.218 [nt.ItemStatePredictedEvent] - GF_LR_HueLight4_Brightness predicted to become 100
2020-04-26 22:35:47.230 [nt.ItemStatePredictedEvent] - GF_LR_HueLight4_ColorTemp predicted to become 14
2020-04-26 22:35:47.243 [vent.ItemStateChangedEvent] - GF_LR_HueLight1_ColorTemp changed from 22 to 14
2020-04-26 22:35:47.246 [vent.ItemStateChangedEvent] - GF_LR_HueLight2_Brightness changed from 0 to 100
2020-04-26 22:35:47.249 [vent.ItemStateChangedEvent] - GF_LR_HueLight2_ColorTemp changed from 22 to 14
2020-04-26 22:35:47.251 [vent.ItemStateChangedEvent] - GF_LR_HueLight3_Brightness changed from 0 to 100
2020-04-26 22:35:47.255 [vent.ItemStateChangedEvent] - GF_LR_HueLight3_ColorTemp changed from 22 to 14
2020-04-26 22:35:47.257 [vent.ItemStateChangedEvent] - GF_LR_HueLight4_Brightness changed from 0 to 100
2020-04-26 22:35:47.260 [vent.ItemStateChangedEvent] - GF_LR_HueLight4_ColorTemp changed from 22 to 14
RESULT:
All lights physically turned on and went to the designated color temp…WIN
Turn the switch off and the lights physically tuned off and the logs were the opposite of on, (no need to show them here)…
HOORAY
Now for the groups:
Revised Rule:
rule "Living Room Spotlights"
when
Item vLivingRoomSpots changed
then
if(vLivingRoomSpots.state == ON)
{
logInfo(logName,"Living Room Spots Test ON")
gLights_LR.sendCommand(100)
gLights_LR_ColorTemp.sendCommand(14)
}
else
{
logInfo(logName,"Living Room Spots Test OFF")
gLights_LR.sendCommand(0)
}
end
LOGS
ON
2020-04-26 22:43:40.347 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command ON
2020-04-26 22:43:40.358 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from OFF to ON
2020-04-26 22:43:40.363 [ome.event.ItemCommandEvent] - Item 'gLights_LR' received command 100
2020-04-26 22:43:40.370 [ome.event.ItemCommandEvent] - Item 'gLights_LR_ColorTemp' received command 14
OFF
2020-04-26 22:44:42.162 [ome.event.ItemCommandEvent] - Item 'vLivingRoomSpots' received command OFF
2020-04-26 22:44:42.181 [vent.ItemStateChangedEvent] - vLivingRoomSpots changed from ON to OFF
2020-04-26 22:44:42.192 [ome.event.ItemCommandEvent] - Item 'gLights_LR' received command 0
RESULT: The logs seem to show the commands executing correctly now, ie no errors but the lights do not physically go on or off?
So I’m back to them being ok when commanded individually but not in a group?
Reading through the group docs now for inspiration…
More randomness…in VS Code I know you can hover over items to see their state…just did so on the gLights_LR and it shows the correct current value but that it has no members
I’d expect to see the dimmer items in there, right?
What makes you think that?
A Group Item is an Item of type Group, but it can also be assigned a errm sub-type of any of the other “ordinary” Item types
Group:Switch Group:Dimmer Group:Rollershutter etc.
That would be why it doesn’t pass commands to its members.
It’s probably all got in a knot with editing; folk seem to sometimes end up with “old” membership lists with in-flight editing, which get resolved at next system boot.
Yes, I edited the post as I realised what I said made no sense so removed it…
I was actually just about to post that I can go into Paper UI, into Items and then add the group to the items, (which I have just done), and now the VS Code shows it as a member and when I run the rule above, it actually works…damn it, it actually works!
I’m going to give the system a reboot shortly and see if it sorts itself out…that’s a few hours of pain I could have avoided!
Thanks for all your help, patience and pointers to date…much appreciated!
Creating/editing Items (including Groups) from PaperUI invokes different mechanisms to creating from xxx.items files, and subsequently editing them.
The end product is the same - an openHAB Item - but the processing is different, so don’t be too alarmed about different behaviour while editing.
Be aware the methods, while they happily co-exist, are essentially incompatible - you cannot edit a file-created Item using PaperUI for example.
Hummmm, rebooted and it’s still the same, I can only add items to groups from the paper ui.
I upgraded from 2.4 to 2.5.4 last week…wonder if there are some settings that I need to change / update…
Simple mode is off on paper ui, but I did notice some errors in the logs on startup regarding my influxdb and a few other bits that weren’t there last reboot, (that I noticed)…
I’ll go and read through the release notes, does any of that make any possible sense as to what has been happening?
It seems unlikely to be anything to do with versions, this stuff hasn’t changed since OH1.
There is no special trick about placing file-based definitions in any order, or even in the same file.
People have run foul of weirdness originating around PaperUI / xxx.items file based Items conflicts, and ended up with a stubborn duff Item lodged in the behind-the-scenes JSONDB. Simple Mode has been at work here too.
Satisfy yourself the process works with brand-new Items created alongside your old ones.
Group:Switch groupFred "group"
Switch Fred1 "gog" (groupFred)
Switch Fred2 "magog" (groupFred)
command ON to group, hover in VSC to see membership, etc.
Yup, that worked like a charm…ok, so it’s looking like the items for the spotlights I have created have all gone a bit funky, I might need to remove all the items relating to the spotlights, ensure they are gone from Paper UI too and then redo the items, but give them new names I suppose???
I would do the removals, reboot, and try again with adding the same names that you prefer. It might still mess up, but then you can just press ahead with new names.
If I recall the underlying problem is about “hanging” links e.g. an Item has been deleted but a channel link to it still exists. I think you’re still fighting a legacy of Simple Mode here.
@rlkoshak I think may be able to tell you how to sort it with manual edits to JSONDB,