New binding available: SolarEdge binding

rossko57 · December 21, 2021, 11:56am

Unfortunately, the state presentation ‘pattern’ (the bit, or ‘pattern’ in
Item metadata) was hijacked years ago to also provide a quantity type Item’s default unit.
It is dual purpose, and so it is difficult to assign a default unit, and then display in a different unit.

This could be done in BasicUI + sitemap by giving an overriding “label [unit]” to the sitemap widget, and auto-conversion will happen.

In MainUI I think you would have to build a custom widget to do your own conversion. Clearly the auto-conversion to arbitrary units is somewhere in the framework for BasicUI, but I don’t think anyone has found how to access it in MainUI.

sirpreis · December 21, 2021, 12:07pm

I am a little confused. I mean, seeing for example 569 Wh and later on 1.5 kWh in any openHAB UI would be fine with me.

The problem I have now is that I would like to use those values in rules and to “calculate stuff”, and I would also like to display charts and numbers in Grafana. Not sure how to do that now that the items has different units throughout the day.

Will I have to create a second item (Aggregate_Production_kWh) and on change of the “production item” (Aggregate_Production) find out if the current unit is Wh and then calculate kWh from that and set it to the Aggregate_Production_kWh item?

rossko57 · December 21, 2021, 12:19pm

That part is easy, you can always get a quantity type Item state in the units of your choice in rules.

Here you depend on persistence, the historic record. That does not record units, so you must ensure your Item always has the same base unit when it is recorded to ensure consistency.

I know persistence uses the Items default unit to reconstruct values when retrieving records.
I am not sure if it uses the default to do a conversion before recording, if the current unit happens not to be the same as default. If it does, everything is good.

I think you need to be sure that is happening first, I would not trust UI displays. Look in your events.log to see real state changes (with units).

sirpreis · December 21, 2021, 12:28pm

Here is a screenshot of my event.log for two items that are set up the exact same way:

So it seems like it just records the value without doing any conversion? That’s what I am seeing in my Grafana panel as well, as:

In a while this will switch over to 1 kWh in Grafana.

rossko57 · December 21, 2021, 1:04pm

Weird stuff happens. A demo -

// test Items - a non-quantity, a quantity with default, and a quantity without default
Number testN "testing  [%.1f kWh]"
Number:Energy testE "testing  [%.1f kWh]"
Number:Energy testX "testing"

// test rule
testN.postUpdate("10")  // no units
testE.postUpdate("10")
testX.postUpdate("10")
Thread::sleep(1000)
testN.postUpdate("15 Wh") 
testE.postUpdate("15 Wh")  // unit doesn't match default
testX.postUpdate("15 Wh")
Thread::sleep(1000)
testN.postUpdate("25 kWh")
testE.postUpdate("25 kWh")
testX.postUpdate("25 kWh")

results

2021-12-21 12:40:22.734 [vent.ItemStateChangedEvent] - testN changed from NULL to 10
2021-12-21 12:40:22.735 [vent.ItemStateChangedEvent] - testE changed from NULL to 10.0 kWh
2021-12-21 12:40:22.736 [vent.ItemStateChangedEvent] - testX changed from NULL to 10

Pretty much what you would expect. A unit is assumed for testE when posting just-a-number. testX is just messed up - no unit given, no default either, pretty meaningless.

2021-12-21 12:40:23.750 [vent.ItemStateChangedEvent] - testN changed from 10 to 0.015 kWh
2021-12-21 12:40:23.757 [vent.ItemStateChangedEvent] - testE changed from 10.0 kWh to 0.015 kWh
2021-12-21 12:40:23.759 [vent.ItemStateChangedEvent] - testX changed from 10 to 15 Wh

Woah, that surprised me. The plain Number Item has actually done an auto-conversion to a default unit. I expected that to load with 15Wh. But of course it isa nonsense posting units to a plain Number - this is just exploring.
testE has done what I expected - auto-converted the update to the default unit, good.
And testX (with no default) just accepts what unit it was given.

2021-12-21 12:40:24.754 [vent.ItemStateChangedEvent] - testN changed from 0.015 kWh to 25 kWh
2021-12-21 12:40:24.762 [vent.ItemStateChangedEvent] - testE changed from 0.015 kWh to 25 kWh
2021-12-21 12:40:24.763 [vent.ItemStateChangedEvent] - testX changed from 15 Wh to 25 kWh

This is all as expected.

Of course this is postUpdate from rules, it is not quite the same as channel updates from a binding.
What we’re not sure of here is exactly what the SolarEdge channel is posting to the Item - with or without units?
You could confirm this by creating test plain Number type Items, with no [default] but perhaps just [%s], and link those to your SolarEdge channels as well as your regular Items. Not all the channels might be alike here.

What I’m driving at here is that if the channel posts updates with units, I would expect the Item to auto-convert to user-defined default unit, which takes care of all your worries.

Note also that when defining Items from text files OH2 style, the [default] given in a label may not end up in the OH3 metadata ‘pattern’. The test Item acting most like your observations is the one with no default assigned. We might have to check this out on your Items.

sirpreis · December 21, 2021, 1:16pm

Wow, thank you for the test!

I was actually looking for the bindings source code, but didn’t find it (right away, didn’t put much time into the search to be honest).

So maybe the update to the items is just incorrect from the bindings site, missing the units, if I understood correctly?

I added a new number item, but right now all of those items are at >= 1 kWh, so it’s hard to see it that changes anything?

rossko57 · December 21, 2021, 1:18pm

I think there is more to it than that, the Wh unit did not appear by itself.
But we must not assume all channels are acting alike.

The screenshot suggests your just-a-Number test is getting updates without units. Do check events.log as well.

sirpreis · December 21, 2021, 1:25pm

Correct, I missed that.

So I guess that could be a “bug” in the binding?

rossko57 · December 21, 2021, 1:31pm

I’m not sure how much the channel interferes with the update, having regard to target Item type. Gather your data for tomorrow and it may make more sense.
You could even try a String type Item, might not work.

sirpreis · December 21, 2021, 2:04pm

Ok, will look at the items tomorrow.

I just put logging for the binding to debug and found this:

2021-12-21 14:59:29.779 [DEBUG] [odel.AbstractDataResponseTransformer] - Channel aggregate_day#production transformed to QuantityType (1.632 kWh) → 1.632 kWh

I have no clue what I’m doing but it looks like there is a unit, at least in the log.

AlexF · December 21, 2021, 3:15pm

I spent quite a lot of time into UOM implementation. Maybe there is still an issue but turning on debug logging should reveal the issue.

sirpreis · December 21, 2021, 3:49pm

Yea, probably an issue on my end. Hopefully I’ll get some sun tomorrow…

sirpreis · December 22, 2021, 1:51pm

I looked into the debug log a little bit. I found this:

2021-12-22 09:14:35.844 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#selfConsumptionForConsumption: 0 kWh
2021-12-22 09:14:35.847 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#production: 0 Wh
2021-12-22 09:14:35.850 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#export: 0 Wh
2021-12-22 09:14:35.854 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#selfConsumptionCoverage: 0 %
2021-12-22 09:14:35.855 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#consumption: 11.063 kWh
2021-12-22 09:14:35.858 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#import: 11.063 kWh

There a difference between selfConsumptionForConsumption, consumption and import channels (kWh) and production and export channels (Wh). That could explain my “issues” described above, couldnt it?

There the log today a little later on:

2021-12-22 13:14:38.003 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#selfConsumptionForConsumption: 0.639 kWh
2021-12-22 13:14:38.004 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#production: 639 Wh
2021-12-22 13:14:38.006 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#export: 0 Wh
2021-12-22 13:14:38.008 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#selfConsumptionCoverage: 3.552171 %
2021-12-22 13:14:38.009 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#consumption: 17.989 kWh
2021-12-22 13:14:38.012 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#import: 17.35 kWh

And here is the same part of the log from yesterday where the the channels were already above 1 kWh:

2021-12-21 14:59:29.792 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#selfConsumptionForConsumption: 1.627 kWh
2021-12-21 14:59:29.794 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#production: 1.632 kWh
2021-12-21 14:59:29.798 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#export: 0.005 kWh
2021-12-21 14:59:29.801 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#selfConsumptionCoverage: 5.8150753 %
2021-12-21 14:59:29.804 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#consumption: 27.979 kWh
2021-12-21 14:59:29.808 [DEBUG] [nternal.handler.SolarEdgeBaseHandler] - Channel is to be updated: solaredge:generic:f300f94ef7:aggregate_day#import: 26.352 kWh

To me it looks like some channels are handled differently by the binding?

rossko57 · December 22, 2021, 2:19pm

That should all be fine.
The binding may post updates in any unit it likes (suitable units of course e.g. for Energy Wh, kWh, J, Ws, etc.) That’s the whole point of including the unit rather than assuming.
Provided the update is passed to the Item through the channel with units, any scaling should be taken care of by the framework.
So far as I believe, if your Item has default units assigned in metadata ‘pattern’ the update will be converted to those units.
If the Item has no default unit, the update is accepted as-is.
Provided the Item is of suitable type e.g. Number:Energy, not just Number.

The missing info to go with your logs is what your Item states change to, shown in events.log.

sirpreis · December 22, 2021, 3:12pm

Ok, I see.

2021-12-22 14:09:34.196 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WR_Aggregate_Day_Production' changed from 942 Wh to 982 Wh
2021-12-22 14:09:34.199 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WR_TestProductionPlain' changed from 942 to 982

2021-12-22 14:14:34.954 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WR_Aggregate_Day_Production' changed from 982 Wh to 1.02 kWh
2021-12-22 14:14:34.956 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WR_TestProductionPlain' changed from 982 to 1.02

Here are the two items:

And:

Where could be the issue then? I feel like I’m back to square one

With metadata pattern you probably mean this?

I have never used that before. What would be the correct syntax here?

sirpreis · December 22, 2021, 3:17pm

Ok, I now added %.2f kWh to the Pattern field. Will see how that goes. Thanks again.

rossko57 · December 22, 2021, 3:20pm

%.1f kWh

In ye olden days, when defining Items from file we embedded that in within the Item label.
Now it’s in the metadata.
Usually when people define Items in OH3 using OH2 style files, the label [content] ends up in metadata.
However you defined your Item we don’t know?

sirpreis · December 22, 2021, 3:32pm

Good question, I’m not completely sure. I probably used my old .items file to re-define them (copy/paste into the “Add items from textual definition” window) when I also switched from the .thing file to a thing created via the UI.

But if I understand correctly that should have made the unit a metadata.

These were the items defined in the items file.

// Number  WR_Aggregate_Day_Production     "Tagesproduktion [%.2f kWh]"                                       {channel="solaredge:generic:se3000:aggregate_day#production"}
// Number  WR_Aggregate_Day_Consumption    "Tagesverbrauch [%.2f kWh]"                                        {channel="solaredge:generic:se3000:aggregate_day#consumption"}
// Number  WR_Aggregate_Day_Export         "Tageseinspeisung [%.2f kWh]"                                      {channel="solaredge:generic:se3000:aggregate_day#export"}
// Number  WR_Live_Consumption_Plus_Export "Summe Aktueller Verbrauch und aktuelle Einspeisung"

rossko57 · December 22, 2021, 3:35pm

Only if the import tool worked completely at the time. It’s not there now.

Have you fixed it now?

sirpreis · December 22, 2021, 3:39pm

Were there times that tool was broken?

Yea, I added the metadata and will check tomorrow if I see “kWh” even when the item is still in the Wh range.