Not from the binding. It’s what the block is retrieving.
Returns the state as a String
Returns the state as a String
Returns the state as a plain number without units, even if the Item is carrying units.
If the Item carries units, returns the state as a Quantity. If you have a Quantity, you must use the Quantity blocks under Units of Measurement to compare to, do math with it, or convert to another unit.
Obviously use your Item names and the comparison you desire.
If you are running openHABian use Frontail. You can access it from the other apps icon (upper right corner of the overview page in MainUI) or same address as your OH instance web UI replacing the 8080 port with 9000.
You can also ssh to the machine and tail the log files (/var/log/openhab/openhab.log and /var/log/openhab/events.log). events.log shows all the changes and commands to your Items and openhab.log will have errors and any log statements made from rules.
Frontail shows these two files in the browser. If you are not running Frontail you need to ssh to the machine. To see them scroll by as they are written use:
tail -f /var/log/openhab/openhab.log
tail -f /var/log/openhab/events.log
Run those in two windows and you can monitor everything that’s going on as it happens. There are other ways but this is the simplest.
See above if you want to keep using units.
Use the “numeric state” if you don’t want to mess with units. Generally, if it’s worth while to have the units in the first place, it’w worth while to use them in your rules.
Yes but it’s generally better to standardize on one or the other. It’s easier to maintain when the same type of thing is written in the same way in the same place.
A literal translation into Blockly (I can’t write in my own name for the Items to I’ll leave them as MyItem, you’ll fill in the Item name as appropriate.
How I would implement it keeping the units (complete with the comparison you’ve not shown). Note, implementation of support for ABS and other math operations for Quantity is in work and should be along before 4.1 release. In the mean time we have to do that ourself.
Note that I’m not 100% this will actually work. There were a bunch of subtle bugs with how math operations work with temperatures which have since been fixed but might still be there in OH 4.0. If you start seeing degrees Kelvin or answers that look like they should be degrees Kelvin that’s why.
Assuming all your
unit metadata is set properly, it would probably be easiest to just work with the numerical state instead of with units. At least until OH 4.1 is released with support for abs and corrections to those bugs.
It’s also worth noting that you can create Rules DSL script actions in the UI also. Create the rule as you are with Blockly, add the triggers, etc. Add a Script Action and choose Rules DSL as the language. Then paste the stuff that appears between “then” and “end” into the action: e.g.
/* cast the Darksky temps to useable number */
var Today_MTemp = (Weather_Temp_Max.state as QuantityType<temperature>).doubleValue
var Tommorrow_MTemp = (Weather_TMax_Tommorrow.state as QuantityType<Temperature>).doubleValue
/* Get the absolute temp change for tomorrow */
var Delta_Temp = Math::abs(Today_MTemp - Tommorrow_MTemp)
Note there are some limitations. Instead of global variables you’ll need to use
sharedCache (see the implicit variables section of the rules docs) and you cannot import anything. But imports are relatively rare and you can use the full classname instead of importing them anyway.