I have a couple of questions about using Blockly.
Problem: Need to change the value of one of these numbers now a string to a new value via a delta num. eg 2,100,100 becomes 4,100,100 or 12,100,55.
Secondly, the delta could be + or - based on some retrieved data. Need Math.abs I guess?
To that end I guess I could do inline script as I saw but would rather keep it all Blockly as part of the experiment.
Thanks
The value is a String. You will have to split the String into is three parts, convert the String to a Number, do the calculation, and then rebuild the String.
What I’m not sure of it’s whether there is a block to parse the String to a Number. The rest have blocks, including Math.abs. (it’s an option of the “square root of” block).
The split is under “text”, calculation under “math” and rebuild the String under “text”
Thanks, I’ve got the basics working but have run into a stumble. You are apparently Mr. units. When I get weather from weather underground it comes in C. Not good if I’m testing for a 2-degree swing. Anyway, I searched the binding and didn’t see a way. Is this a case where I’ll have to get out of the UI and into the config files and create and item with a format… less the UI hand holding?
I’m not suer what °C has to do with testing for a 2-degree swing,
So assuming you want °F? Then set the unit metadata to °F. What ever the binding sends will be converted to °F before the Item is updated, even if the binding is sending °C.
In the rule use the Quantity blocks to do the math or comparisons.
As long as the units are compatible, you can compare them or do math with them.
So if we assume that your Item is in °C and you want to see if the current value is 2 °F different from the last reading you can do that.
In the above, it doesn’t matter what units the state of “MyItem” is using, as long as it’s compatible with temperature.
I looked all over that metadata and didn’t see a thing, I also set my local units to imperial which I think should have worked? Possible it’s needing to read at reboot. I search the docs for metadata but nothing pointed to setting up for C or F.
I’m just slow I guess??
Can you point me to the right place?
I don’t know what you are expecting to see. There’s one value and you need to enter the unit you want to use.
Settings → Items → YourTemperatureItem → Add Metadata → Unit
It won’t take effect until the Item is updated.
Rich
Thanks, please let me know if I ever reach irritant status. I read a dialog between you and @#$% that highlight the irritation caused by us newbies. Don’t want to get to that point. I have thick skin so
If I ever ask too much, or too frequently please just tell me. I’ll slither off and spend more time digging on my own.
When I did openhab2 there was a lot of ancillary info out there for 4…not so much unless you speak German.
Again, thanks for all the help!!!
Cliff
Oh, by the way I was comparing temps between today and tomorrow and if 2 degrees I’d change lamp color. 28 → 30 vs 82.4 - 86 = 3.6F. Except for transitions from summer to winter here in FL we can be the same temp for weeks. I want to see my weather light “do something” ergo 2F.
Thanks again.
It’s only irritating when the person asking for help is argumentative, refuses to answer questions or provide requested information, or just wants us to do it all for them. You are a long way from that.
Sometimes my replies are more terse than normal based on my time and what sort of device I’m replying on and I think they sometimes come across as being irritated. But usually it’s just I’m in a hurry and can answer this one quickly.
Given the total range of temps is going to be relatively small compared to the total range of hues, you might consider breaking it up even more. There are 360 possible hues but the temp range even here at 7000’ in CO is usually only between -20 °F to 90 °F (sometimes with a 50-60 °F swing in a single day) leaving way more than half of all the colors on the table.
I would probably make this way too complicated. I’d dedicate certain ranges of colors to some ranges of temperature. For example, purples for anything below freezing, blues for freezing to say 45 °F, yellows for 45 °F to say 70 °F. orange for 70 °F to 80 °F and anything over 80 °F red.
It would probably work better if the ranges were a little more even but you get the idea.
Then, for each temperature change I’d map the temperature to a color in that range. For example, I’d try to evenly map the purple temps between 250 and 270, the blues between 250 and 200, yellows between 50 and 70, oranges between 20 and 40 and the reds between 350 and 20.
I’ve not really looked at what that would look like and would expect some tuning to be required. But you kind of get the idea I hope. The main point is that there isn’t a one-to-one mapping between temperature and a movement of the hue and that we jump around the color wheel to select a color that is intuitively related to the temperature range.
Your colors and ranges might be different. You have way less variability in FL so might need to use fewer colors and bigger jumps.
That would be fun and cool. I’m sure that you don’t recall I was modeling this after the Milwaukee Gas Building. Wisconsin Gas Building - Wikipedia.
During the 14 (cold years) I lived up there I could walk out and see tomorrow’s weather. (see poem in wiki)
My V2 design goal is to extend the colors to 6 shades of the three colors.
Slight change in hue will map to bigger temp swing vs minimum of 2 degrees. I might have 2 or 3 shades red or gold. AKA a lot warmer/colder.
Final, you had helped me with the recursive call that blinked the light for rain (it would be snow for you 
). Now if the probability of precipitation is really high I’ll agitate (blink) rapidly. Low, more slowly. It will take me less time to code than explain again to neighbors.
The ones who know it, love it. They can see as they drive by tomorrow’s weather. Albeit, FL weather is not too exciting. It’s mostly blue all the time.
The light comes from a Hue bulb inside this concrete casting I made.
More fun than turning on my bedroom light!!!
I do remember this project! I just don’t always remember who’s working on what.
That might be better implemented differently these days. In particular, if using Blockly, see Rules Blockly - Timers & Delays | openHAB, though note that I think there is a bug in that for versions of OH prior to 4.0.4 so make sure you have the latest release.
Well, I’ve got my color code alg working correctly but that age old problem of units. The return from weather is a string, and I need to compare today’s high temp to tomorrows.
I saw a dialog between you and blockly maintainer. You offered a way and he offered a way of using blockly.
In OH2 I used this code in a rule…
when
Channel 'astro:sun:local:minus30:civilDusk#event' triggered START
// Time cron "0 0/1 * * * ? *"
then
/* 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)
At this stage of the game, I’m trying to stay in Blockly for simplicity. That and I’m unclear how I combine worlds between UI and files. If they coexist cleanly, that is the easiest path, just port my code.
I wish there was a better way to examine values when debugging. If there is a monitor on the raspberry pi, does output to console show stuff?
What is the preferred method to extract/convert the item’s temp to a number for use in math.
Cliff
Can UI and config files exist and function together? Do they read both UI generated stuff and files?
Not from the binding. It’s what the block is retrieving.
Returns the state as a String
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.
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 privateCache or 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.
I’ll try this again, all my emails were getting kicked back because OH profile was different.
Cliff