Item state w/o binding


I have some 433MHz remote plugs to control lights, and in addition some more elaborate Homematic light switches (linked in OH2 via Homematic binding). The remote plugs are defined as Switch items via the Smart Home Designer, and both sorts of lights can be properly switched on and off through the OH2 app via an according sitemap.
Now I picked some of the remote plug lights and some of the Homematic-controlled lights and have put them into a group called “Random Lights in absence”, which – guess what – are randomly switched on and off for random periods in the evening if nobody is at home. A corresponding rule randomly toggles the state of individual group members. This works great for the Homematic switched lights, however it doesn’t for the remote plug switches. They ultimately end up all being switched on, but at no time are switched back off, since the toggle code never detects them being already on. So I can send ON to the plugs (which will then trigger another rule reacting to the state change and send the right 433MHz signal to the plug), BUT the item seems not to store that ON state. When next being asked, it reports OFF again. I tried with an additional postUpdate call, but it makes no difference.
As the Homematic switches do toggle correctly (because they also report ON state after being switched on), I suppose it is somehow related to the plugs not having a linked binding? From all reading I can’t deduct though that a simple switch item definition shouldn’t be sufficient to make it retain a set state.
Any hints on this topic? I read a lot about that by now, but couldn’t make up my mind why it doesn’t work and what would solve it.

Regards, habitoti

You might have already deducted the reason, however without seeing your item definition (especially a non Homematc item) and the rule coming up with a solution isn’t easy.

I’m using those 433mhz plugs also, one (rather old) type only toggles (i.e. no specific ON or OFF), the newer ones have separated ON and OFF commands.


it’s clear that those simple 433 MHz plugs don’t report their actual state, but that is also not my problem here. The items have an assigned rule, and depending on state change either an ON or OFF command is sent via pilight.

My plug items are defined like this:

Group:Switch:AND(ON,OFF) LightsRandomWhenAbsent "Random lights in absence"
Switch plug1 "Lamp 1" (LightsRandomWhenAbsent)
Switch plug2 "Lamp 2" (LightsRandomWhenAbsent)

Such a plug is switched like this (though this is not relevant here, I believe)

rule "Plug 1 On/Off"
    Item plug1 received update
    if (plug1.state == ON) {
        executeCommandLine("pilight-send -p elro_800_switch -u 1 -s 19 --on")
    } else {
        executeCommandLine("pilight-send -p elro_800_switch -u 1 -s 19 --off")

So as this works and I can switch lights on and off (which looks like item state is actually persisted!), I would have assumed that my random rule should work as well. It picks every 10 minutes a random member of the group and toggles it’s state (after a random delay of up to 5 minutes).

rule "Randomly turn on & off lights between 06.00-0.00 if before or after sunset and if alarm is activated"
	Time cron "0 */10 6-23 * * ?" 
	or Item AlarmActivated changed
	if (AlarmActivated.state == ON 
		&& (now.isBefore((Sunrise_Time.state as DateTimeType).calendar.timeInMillis) 
			|| now.isAfter((Sunset_Time.state as DateTimeType).calendar.timeInMillis))) {

 		// Create a timer with a random delay value (min 5 s, up to 5min)
		var int randomTime = 5+(new java.util.Random).nextInt(295)
		logInfo("org.openhab","Setting random lights timer to " + randomTime + " seconds.")
		tRandomLights = createTimer(now.plusSeconds(randomTime)) [ |
			if (AlarmActivated.state == ON) {
				// only if alarm is still active when timer comes back!
				var rndLightIndex = (new java.util.Random).nextInt(LightsRandomWhenAbsent.members.size)
				var rndLight = LightsRandomWhenAbsent.members.get(rndLightIndex)
	 			var rndLightStateNew = ON
	 			if (rndLight.state == ON) rndLightStateNew = OFF
	 			logInfo("org.openhab","Switching light " + + " from " + rndLight.state + " to " + rndLightStateNew)

In this case, however, the plug items (w/o specific binding) always read OFF state (and so are always switched ON again only), while my Homematic switches (which also know their true states) do work as expected and toggle correctly. So I am not sure whether there is a side effect when picking the binding-less switches from a group that makes them loose their state or report wrongly. It all doesn’t make much sense to me, so I might also try just to start from scratch… :frowning:

Regards, habitoti

Your random rule sends commands to items. Your on/off rule listens for updates. These are not the same thing.
If you change your on/off rule to listen for commands, you’ll probably want to update the item yourself as well to record the state, where no feedback from the device is available.

The ON/OFF rules just tracks the item state changes and generates the required pilight commands to sync to the physical world. As I said it’s not really related to the issue and just posted for completeness. The random rule now just tells those items to change their state to ON or OFF, and sendCommand just does this (and also should be the natural way to control a Switch item).
So having said this, I just found that the problem is rather trivial and just one of those unexplainable internal OpenHAB twists it sometimes gets into after changing, adding and assigning stuff. A simple reboot, removing and re-adding the switch plug items and re-assigning them to the group and then – for safety – another reboot got everything straight and that exact code now works just fine.

Yes, that was my point. The on/off rule, that acts in lieu of a binding, should listen for commands in order to behave more like a binding.