So it’s a string item with the values for the whole day. I want to get a notification, if just one “total” value is under 0.20. How do I get this in a rule, I really have no idea how to do it, because there are 24 “total” values. The best would be, if I also get the startsAt value (or just the time of it) in this notification.
Can someone help me with this array?
The item is called Tibber_API_Prices_for_tomorrow_as_a_JSON_array
You have several approaches you can do but they depend on what binding you are using to retrieve these values.
Assuming the HTTP or MQTT binding or binding that lets you create your own channels, and assuming it’s always 24 values and always in chronological order I would implement this at the binding level. Create one Channel for each entry with the JSONPATH to select the “total” for a given array element ($[0].total, $[1].total, and so on, see JsonPath - Transformation Services | openHAB). Make sure to name the element based on the time it represents. Link each Channel to a Number Item, again named/labeled with the time that value represents. Add the Items to a Group.
In a Rule you can sort the members of the Group to find the minimum and then use the name or label of the Item to extract which time is at the lowest value. See Design Pattern: Encoding and Accessing Values in Rules for further details.
If it isn’t an option to implement this at the Thing with Channels but the rest of my assumptions hold true I’d implement the same approach except using the transform Profile. You’d only have the one Channel but link that to the same 24 Items and use the transform Profile to extract the element for the given Item. Still use the Item name/label to identify which time the value represents.
In general, it’s going to be easier if you can get that bid array into Items. Once you have that it becomes a straight forward OH problem.
If my other assumptions do not hold true, you’ll need to write a rule to parse the JSON and extract/manipulate the values. But if you choose JavaScript, you are in luck as the JS in JSON stands for JavaScript. Call JSON.parse(items.Tibber_API_Prices_for_tomorrow_as_a_JSON_array.state) and you will have converted the JSON into a JS Object which can be processed using normal coding tools.
Found this thread as I’m about to refactor my rules (again).
What TO means is the dynamic prices of Tibber. The binding won’t create hourly items (awattar binding does), but give you the “today”-Prices and the “tomorrow”-Prices as JSON.
This would result in 48 items, because the time span would be two days.
which brings me to the following point/question.
The typical use cases would be to calculate periods of high prices and low prices - and to be able to reference them for live triggers in rules - or projected triggers.
example:
if it’s currently a low price period I would turn on my heater
knowing, if there’s an even lower price period in two hours time, I would postpone the heater for that.
knowing, my heater has to run for 4hours, I would even move this to a period of continous 4hour period (or even better split it in two periods of 2hours…)
If I remember correctly there was a discussion here sometime in spring, but I don’t find the thread, sadly. Because with awatter-Binding I can define such periods as seperate things - and the binding provides triggers for a number of consumers like EVs, heaters, …
there even was a JSON-example in JS Scripting, if I’m not completely mistaken… But I don’t find it.
but the question I’m facing right now: is it better to have those 24 items and to iterate them in a way, or to do that with JSON.parse? JSON.parse seems less bulky, but then you have to somehow persist the calculation, so you don’t have to parse it frequently (the prices only change once a day).
Items don’t really cost anything so that by itself doesn’t seem like an argument for or against any given approach.
It’s all largely going to be driven by how these need to be used in your rules and how comfortable you are in code. There are a ton of approaches that are possible.
Also, in 4.1 one of the big new features is that persistence now supports storing future states for Items (not supported by MapDB and rrd4j of course). And when that time comes, persistence will update the Item to that value. So maybe that’s an approach you can use.
What I don’t know is if that has been exposed to rules or whether it’s only available to bindings right now. It’s definitely supported by the REST API though.
But if you were to do it in a rule using JSON.parse, storing stuff that can be used within the same rule or other rules is the whole purpose of the cache. JavaScript Scripting - Automation | openHAB. Stuff stored in the shared cache can be used by any rule. So you could parse the JSON, manipulate or reduce it to just what you need and store that in the shared cache. Other rules that need that info can pull it from the shared cache.
Though if you need to generate events to trigger rules, you’ll need to set timers to command Items or call other rules directly.
Thanks for your food for thoughts. again!
I’ll have to look into that future states stuff. Sounds nice - even more so for visualizing the energy prices (better WAF ).
ATM I’m thinking of doing it in part like the awattar-binding does (I don’t know how much longer awatter allows anonymous use of their API anyways). So I’m getting the tibber prices daily and after that I’d calculate the respective “cheap” hours given from the Tibber API already in regard to being “cheap” as “cheap er” than the last days - and the “really cheap” hours, which I define as “cheap” (below a certain threshold). Same goes for expensive. And also device-specific “there you should/can run”-hours.
Example: tonight the prices are “cheap” for a looooong time:
So my Whirlpool would normally start thinking “below 20cts? let’s go for it” and would heat through the night. Normally we won’t use it until afternoon, so the “cheaper” way would be to wait until 11ish and then start heating up.
So I would create an item “Whirlpool_BestTimes” and put in something like [11,12,13,14,15,16] to cover the “cheap” timeframe until we’re likely get in. and the pool won’t heat through the (cold winter-)nights…
