<Item>.changeCommand(<State>)

Tags: #<Tag:0x00007efed86878f0>

Hey guys. I want to hear your opinion about something that I have in my head for months now.

I have some rules firing on every change of the outside illuminance (Lux) to adapt the lights indoors. While this is very useful when it’s dawn or dusk, it just spams the indoor lights with OFF commands every few seconds, cluttering the radio network.

It could be useful to have something like sendCommand that only sends the command, when it’s different from the current state. I am aware that I can do this using procedures, but I am really interested in your opinions about this and if you really like it, it might even get into some of the next releases.

I very much second that, this were a useful addition indeed. I just recently stared longingly at my screen when I learned such an expression exists in Jython

whole post is here: Lucid script step by step ... (Jython scripting tutorial using lucid,jsr223 Jython helper library)

Of course, I can (and do) write some code in a rule and check the state first before issuing a sendCommand…but it is not very elegant.

1 Like
rule "light change"
when
    Item luxitem changed
then
    if (lightitem.state != OFF) lightitem.sendCommand(OFF)
end

I appreciate your motivation to provide me a quick and working solution. I really hope to talk about possible implementation pro’s and con’s in the rules DSL (like in Jython, above), though.

I do like the idea. It is an addition that would not disrupt much of existing Rules yet give us another tool to use to simplify our Rules a bit.

I envision either a flag to pass to the method: (e.g. sendCommand(newState, true) where if the flag is true or present it doesn’t send the command or post the update if the state is the same. This would be more consistent with how the persistence methods work. Of course, new method names would work as well.

Both the Item methods and the Actions would have to be updated.

1 Like

I like your idea of having an overloaded method of sendCommand with a different number of parameters more than my initial idea. I wonder if we could pack any useful information into that second parameter, instead of true to only send on change or false or nothing (the sendCommand with one parameter, that we already have) to send the command regardless.

Maybe the a Time definition of a point in time that we want to compare. Like sendCommand(newState, now) for the behaviour we are talking about right now and sendCommand(newState, now.minusHours(1)) to send the command only if it is different than the state of one hour ago.

Does this make sense?

It makes sense but I’m not sure I’m comfortable with only having this capability if I’m using persistence and even beyond that I’m not using MapDB or rrd4j. And to be consistent we would need to support passing in the name of the persistence engine we want to query the state for as the default engine may not be the one with the right data. So this balloons to three methods each:

- item.sendCommand(state)
- item.sendCommand(state, datetime)
- item.sendCommand(state, datetime, persistence engine name)

What happens if the Item is not saved to persistence? We would need some way to detect and catch that error. With the other persistence methods they return null, but as far as I’m aware, sendCommand doesn’t return anything.

The use case doesn’t feel compelling enough to justify the added complexity IMHO. I’ve seen far more frequently the case where we want to avoid sending a command when the new state is the same, but I can’t think of a case where I’ve seen not wanting to send a command when the new state is the same as it was some time in the past. Doesn’t mean that use case doesn’t exist, but it is somewhat rare.

You are right, I was getting of track there :sweat_smile:. Didn’t think of the persistence engines and error cases, too.