What i want to achieve:
When the wind speed increases to more than 4, then switch the fountain off as the water blows everywhere and empties the fountain.
My approach:
Using OH3 I have a switch called ‘TooWindy’ that gets turned on and off by updates to a weather item. Changes to the TooWindy item then get used in further rules like turning on/off the fountain and closing windows/awning etc.
The problem:
The TooWindy switch never gets changed. Another problem ive come across is i cant increase the logging levels for the openweathermap binding.
Here’s the rule:
rule "is it too windy"
when Item localCurrentWindSpeed received update
then
if (localCurrentWindSpeed.state > 4)
{
// sendCommand(TooWindy, ON)
TooWindy.sendCommand("ON")
}
end
In addition to the automated conversion the NumberItem linked to a Channel delivering QuantityTypes can be configured to always have state updates converted to a specific unit. The unit given in the state description is parsed and then used for conversion (if necessary). The framework assumes that the unit to parse is always the last token in the state description.
Maybe the other way … assuming the state is a string due to the km/h unit … so your original script compare a string to a number. So make a number of the state?
var speed = 1*localCurrentWindSpeed.state.substring(0,localCurrentWindSpeed.state.indexOf(" "));
if (speed > 4)
etc
@jswim788 has the root cause of this problem. You need to compare QuantityTypes with QuantityTypes. Unfortunately, if the binding publishes a QuantityType, you have to deal with QuantityTypes. You can’t “down grade” it by just defining the Item as a plain old Number.
One other thing I notice is there’s no point in running this rule unless the wind speed actually changed. So I’d use changed instead of received update.
You don’t show your other rules but if any of them are triggered by TooWindy (which is what I would expect) you might want to check if the Item is already ON before commanding it ON again, or make sure your other rules are triggered by changed instead of received update or received command. That will prevent a bunch of rules running when there is no need to.
Thanks for the replies! The link is great, although i think i will need to read that more than once to fully understand.
@rlkoshak the reason i didnt use ‘changed’ was that the weather binding only seems to send an update to a parameter when there is actually a change. However, that was probably a bit short sighted and what you recommend feels like a better approach, so thanks
Colin
This sentence shows perhaps a misunderstanding on how Item events work.
When an Item changes for any reason, a changed event will occur. This event is generated by the Item any time it changes.
An update is issued by a binding or a Rule. This is a request to have the Item take on the given state. An update may or may not result in a changed event as the Item may already be in that state. But a changed event will always be proceeded by an update.
A command is issued by a binding, a Rule, or the UI. This is a request to cause something to happen. A command may or may not result in an update to the Item. If it does result in a update, it may or may not update the Item to the command itself. For example, if you send INCREASE as a command to a Dimmer Item, the Item’s state doesn’t become INCREASE, instead it becomes its current state plus some increment (the increment amount is often determined by the binding).
This table might help.
Item Type
Current State
Command
Update
Change
Description
Switch
ON
OFF
OFF
OFF
The command triggers and update, the update triggers a change
Dimmer
50
INCREASE
55
55
The INCREASE results in an update to 55 which triggers a change
Dimmer
100
INCREASE
100
The command results in an update but there is no change because 100 is the max value a Dimmer can have
Switch
ON
OFF
There are cases where a command does not directly result in an update and therefore there won’t be a change either
Only commands and updates can be issued by you or parts of the system you control. change events happen automatically when the Item actually changes state.
