New binding available: SolarEdge binding

I just tried to remove the thing file, the jar, rebooted the server, put the thing file back, and downloaded http://friese-de.eu/openhab2/org.openhab.binding.solaredge-2.4.0-SNAPSHOT.jar to the addon folder.
It’s pulling the info from solaredge, but afterwards, my logs are filled every 30 seconds with the java error.

 ==> log/events.log <==
 2018-06-13 17:06:19.046 [hingStatusInfoChangedEvent] - 'solaredge:generic:se15000' changed from UNINITIALIZED to INITIALIZING
 2018-06-13 17:06:19.366 [hingStatusInfoChangedEvent] - 'solaredge:generic:se15000' changed from INITIALIZING to ONLINE: logged in
 2018-06-13 17:06:20.344 [vent.ItemStateChangedEvent] - se15000_DProd changed from NULL to 33.24
 2018-06-13 17:06:20.344 [vent.ItemStateChangedEvent] - se15000_MProd changed from NULL to 491.9
 2018-06-13 17:06:20.344 [vent.ItemStateChangedEvent] - se15000_YProd changed from NULL to 2536
 2018-06-13 17:06:20.372 [vent.ItemStateChangedEvent] - se15000_WProd changed from NULL to 266.86
 
 ==> log/openhab.log <==
 2018-06-13 17:04:36.667 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'solaredge.things'
 2018-06-13 17:06:18.690 [INFO ] [org.apache.felix.fileinstall        ] - Installing bundle org.openhab.binding.solaredge;singleton:=true / 2.4.0.201806111309
 2018-06-13 17:06:19.011 [INFO ] [org.apache.felix.fileinstall        ] - Started bundle: file:/usr/share/openhab2/addons/org.openhab.binding.solaredge-2.4.0-SNAPSHOT.jar
 2018-06-13 17:06:19.049 [INFO ] [laredge.handler.SolarEdgeBaseHandler] - About to initialize SolarEdge
 2018-06-13 17:06:20.191 [INFO ] [clipse.jetty.client.ResponseNotifier] - Exception while notifying listener org.openhab.binding.solaredge.internal.command.LiveDataUpdate@5facd804
 java.lang.NullPointerException: null
    at org.openhab.binding.solaredge.internal.model.LiveDataResponse.getValues(LiveDataResponse.java:108) [246:org.openhab.binding.solaredge:2.4.0.201806111309]
    at org.openhab.binding.solaredge.internal.command.LiveDataUpdate.onComplete(LiveDataUpdate.java:68) [246:org.openhab.binding.solaredge:2.4.0.201806111309]
    at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:193) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:185) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:458) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:405) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:277) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1617) [75:org.eclipse.jetty.http:9.3.21.v20170918]
    at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1350) [75:org.eclipse.jetty.http:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:159) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:120) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:70) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:90) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:115) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at java.lang.Thread.run(Thread.java:748) [?:?]
 2018-06-13 17:06:50.165 [INFO ] [clipse.jetty.client.ResponseNotifier] - Exception while notifying listener org.openhab.binding.solaredge.internal.command.LiveDataUpdate@563864e
 java.lang.NullPointerException: null
    at org.openhab.binding.solaredge.internal.model.LiveDataResponse.getValues(LiveDataResponse.java:108) [246:org.openhab.binding.solaredge:2.4.0.201806111309]
    at org.openhab.binding.solaredge.internal.command.LiveDataUpdate.onComplete(LiveDataUpdate.java:68) [246:org.openhab.binding.solaredge:2.4.0.201806111309]
    at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:193) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.ResponseNotifier.notifyComplete(ResponseNotifier.java:185) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.HttpReceiver.terminateResponse(HttpReceiver.java:458) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.HttpReceiver.responseSuccess(HttpReceiver.java:405) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.messageComplete(HttpReceiverOverHTTP.java:277) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1617) [75:org.eclipse.jetty.http:9.3.21.v20170918]
    at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1350) [75:org.eclipse.jetty.http:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:159) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:120) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:70) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:90) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:115) [72:org.eclipse.jetty.client:9.3.21.v20170918]
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:251) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [76:org.eclipse.jetty.io:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [87:org.eclipse.jetty.util:9.3.21.v20170918]
    at java.lang.Thread.run(Thread.java:748) [?:?]

Let me know if I can do anything to test to solve this…

I found the error at least I believe so. I think siteCurrentPowerFlow is not null but the connections list is null.
I have never seen this in my setup. Do you have such a energy meter connected to your inverter?
Otherwise you should use the legacy mode. That will run other code.

Nevertheless I have fixed the error now but I believe it will not return any data if you do not have a meter installed. But maybe the guys from solaredge changed the behaviour of the API and you will at least get the live production.

It seems to be better.

I also found an error in my items file. With moving around the files a lot, I had suddenly a weird character (1/4) in my item line. Maybe this could also caused the error before?

I’m getting following error now in my log. Not sure if it’s related with the binding, or something more global. Will try to find out later out. At first sight, the data is being processed correctly. I don’t have a meter or so, and I’m running in LegacyMode.

log/openhab.log:2018-06-14 13:37:05.428 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler GenericSolarEdgeHandler of thing solaredge:generic:se15000 tried updating channel live#production although the handler was already disposed.
log/openhab.log:2018-06-14 13:37:35.539 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler GenericSolarEdgeHandler of thing solaredge:generic:se15000 tried updating channel live#production although the handler was already disposed.
log/openhab.log:2018-06-14 13:38:05.641 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler GenericSolarEdgeHandler of thing solaredge:generic:se15000 tried updating channel live#production although the handler was already disposed.

At least before when you got the exceptions it was NOT running in legacy mode.
The warnings you have now occour when you update the binding without restarting openhab. It does not matter.

You are right. I noticed at one moment that I had written LegacyMode=true. And changed it to legacyMode=true. Not sure if that really matters, but it’s the only difference I can think about that change the mode…

Indeed, the warnings are gone after a complete restart.

Thanks a lot !!!

The latest version will not cause any exceptions if you switch off the legacy mode, again. But I believe that you will still not get any live data then. You could give it a try and report back if you want.

BR
Alex

Any idea what this warning/error is? I lost my data feed the other day so have been attempting to get the binding updated, I seem to get a whole heap of aggregate data (which I don’t need/want) but cannot get a live production figure? I did as per brononius, removing thing and jar, rebooting and adding new ones, attempting to re-link channels via Paper etc., but no luck

2018-06-18 13:41:12.553 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler GenericSolarEdgeHandler tried updating the thing status although the handler was already disposed.

EDIT sorry just saw brononius had had the exact same error?
Is there a way of getting the “live” production figure now or is it no longer working? An issue with using the API method is that I already have pvoutput.org pulling data from that, so the 300 calls would have to be shared between them. Might not be that much of an issue if it can be setup so the calls are only done during daylight hours?

For reference:

I’ve just gave it a try, and you’re right.
No live data when I’m using not the legacy mode, and without a meter…

For the moment, it’s working for me (I’m a very happy guy!).

As Alex said: when you don’t have a local meter installed, you should use the legacyMode=true. I had a typo in there. I had LegacyMode (with a capital L). Not sure if it’s case sensitive, but after changing that, rebooting, it seems to be OK…

My current solaredge configs

Addon version
Download: http://friese-de.eu/openhab2/org.openhab.binding.solaredge-2.4.0-SNAPSHOT.jar

ssh -p 8101 openhab@localhost
...
                    2.3.0
                    Release Build
...
openhab> bundle:list | grep Solar
189 │ Active   │  80 │ 2.4.0.201806141009     │ SolarEdge Binding**

My thing file:

solaredge:generic:se15000       [ solarId="MyID", token="MyVeryLongToken", legacyMode=true ]

My items

Number   se15000_Prod    "Huidige productie [%.2f kW]" <sun>   (BU_solar)   { channel="solaredge:generic:se15000:live#production" }
Number   se15000_DProd   "Productie Dag [%.2f kW]"     <line>               { channel="solaredge:generic:se15000:aggregate_day#production" }
Number   se15000_WProd   "Productie Week [%.2f kW]"    <line>               { channel="solaredge:generic:se15000:aggregate_week#production" }
Number   se15000_MProd   "Productie Maand [%.2f kW]"   <line>               { channel="solaredge:generic:se15000:aggregate_month#production" }
Number   se15000_YProd   "Productie Jaar [%.2f kW]"    <line>               { channel="solaredge:generic:se15000:aggregate_year#production" }
Group    BU_solar        "Zonnepanelen grafieken"                  

My rrd4j (graphs)

ctr5min.def=COUNTER,900,0,U,300                                                                                                                                                                                                                          
ctr5min.archives=AVERAGE,0.5,1,365:AVERAGE,0.5,7,300                                                                                                                                                                                                     
ctr5min.items=WO_hOUNTER,900,0,U,300                                                                                                                                                                                                                     
ctr5min.archives=AVERAGE,0.5,1,365:AVERAGE,0.5,7,300                                                                                                                                                                                                     
ctr5min.items=BU_solar 

My sitemap

Group item=BU_Zonnepanelen { 
     Frame label="Productie" {
        Text item=se15000_Prod
        Text item=se15000_DProd
        Text item=se15000_WProd
        Text item=se15000_MProd
        Text item=se15000_YProd
        }
     Frame label="Meer" {
        Chart item=BU_solar period=24h
        Chart item=BU_solar period=W
        Chart item=BU_solar period=M
        Chart item=BU_solar period=Y
        }                        
     }

Hi Ben, mine is set to legacyMode=true and hasn’t changed

From the start I’ve had issues getting things connected, this is my first and only Binding / Thing but I believe I’ve followed all instructions I can find on setting such things up. Seemed that despite my file-based settings being seemingly exactly as they should have been I never got anything connected until I changed some settings in PaperUI, which I think ended up with a whole new Paper-based Thing which took the place of my file-based definitions; eg. I believe it created “solaredge:generic:f522cb85” which linked to my Item “SE5000H_Live_Production”, rather than the “solaredge:generic:SE5000H” I had defined in my solaredge.thing

I’ve checked the bundle|list and it’s showing only one solaredge binding active, with the latest version’s date

This seems to be the recurring error now, perpetually in-and-out

2018-06-18 16:40:08.520 [hingStatusInfoChangedEvent] - 'solaredge:generic:f522cb85' changed from OFFLINE (COMMUNICATION_ERROR): Found to ONLINE: logged in

==> /var/log/openhab2/openhab.log <==

2018-06-18 16:42:35.667 [DEBUG] [dge.handler.SolarEdgeLiveDataPolling] - polling SolarEdge live data org.openhab.binding.solaredge.config.SolarEdgeConfiguration@17bb9e0[token=reallylongtokenID,solarId=123456,legacyMode=true,live data pollingInterval=300,aggregate data pollingInterval=3000,asyncTimeout=120,syncTimeout=120]

2018-06-18 16:42:37.094 [DEBUG] [nternal.command.LegacyLiveDataUpdate] - HTTP response 302

2018-06-18 16:42:37.099 [DEBUG] [nternal.command.LegacyLiveDataUpdate] - onComplete()

==> /var/log/openhab2/events.log <==

2018-06-18 16:42:37.281 [hingStatusInfoChangedEvent] - 'solaredge:generic:f522cb85' changed from ONLINE: logged in to OFFLINE (COMMUNICATION_ERROR): Found

==> /var/log/openhab2/openhab.log <==

2018-06-18 16:42:38.287 [DEBUG] [laredge.internal.command.PseudoLogin] - received content, length: 27

2018-06-18 16:42:38.290 [DEBUG] [laredge.internal.command.PseudoLogin] - HTTP response 200

2018-06-18 16:42:38.686 [DEBUG] [nal.command.PostLoginGetClientCookie] - HTTP response 200

==> /var/log/openhab2/events.log <==

2018-06-18 16:42:38.705 [hingStatusInfoChangedEvent] - 'solaredge:generic:f522cb85' changed from OFFLINE (COMMUNICATION_ERROR): Found to ONLINE: logged in

I can reproduce the error. It seems that solaredge has changed the API.
If you are using the latest version, could you please try to set the legacy mode to “off”. According to documentation the API should have a fallback which returns the AC production if no meter is present.

EDIT: My first assumption was that the URL has changed but I checked in my browser - it is still valid and returning data as expected.

Hi Alex, I just tried turning off Legacy; I don’t get the error anymore but don’t get any production values;

2018-06-19 07:57:30.701 [DEBUG] [edge.internal.command.LiveDataUpdate] - JSON String: {"siteCurrentPowerFlow":{}}
2018-06-19 07:57:30.706 [DEBUG] [laredge.handler.SolarEdgeBaseHandler] - Handling channel update.
2018-06-19 07:57:30.709 [DEBUG] [laredge.handler.SolarEdgeBaseHandler] - Channel is to be updated: live#import: 0.0
2018-06-19 07:57:30.714 [DEBUG] [laredge.handler.SolarEdgeBaseHandler] - Channel is to be updated: live#export: 0.0
2018-06-19 07:57:30.717 [DEBUG] [laredge.handler.SolarEdgeBaseHandler] - Channel is to be updated: live#battery_charge_discharge: 0.0
2018-06-19 07:57:30.721 [DEBUG] [laredge.handler.SolarEdgeBaseHandler] - Channel is to be updated: live#battery_charge: 0.0
2018-06-19 07:57:30.725 [DEBUG] [laredge.handler.SolarEdgeBaseHandler] - Channel is to be updated: live#battery_discharge: 0.0

If I hit the API with my site ID and API key I still get the live production data, at the moment (early morning, sun not kicking in yet) I’m getting 103.4W of generation, so it seems “live#export” does not include this

https://monitoringapi.solaredge.com/site/123456/overview.json?api_key=APIKEYID

If need be I can probably send you my siteID and API Key to help debugging, I don’t think there’s any way they can be used to adversely effect my system and my production data is out there for all to see on pvoutput

PS. is it possible to disable the Aggregate Data collection? I don’t need this (I’ll check it in the solaredge monitor if required) and seems to be pulling down a whole heap of data

1 Like

@roguestreak
Thank you! I thought I went nuts.
I have the same issues as you, not getting any live data (empty “JSON String: {“siteCurrentPowerFlow”:{}}”) and was looking/blaming my configuration.

@AlexF
If there is anything I can do help to solve this problem, config/logging/debugging, please let me know.

Hi @roguestreak and @Meduza,

thanks for your feedback. It would help to get your SiteId and API_KEY or SiteId and a valid SPRING_SECURITY_REMEMBER_ME_COOKIE.

Also the ‘SPRING_SECURITY_REMEMBER_ME_COOKIE’ is valid for mor than 50 years it can be made invalid by changing the accounts password. So you do not need to give me access forever.

BR
Alex

Thanks Alex, I’ve sent the details via Message

Just an update:

I am currently working on a new version which will again support those setups which do not include a meter.
I will switch over to the official API which has a limit of 300 calls per day but I see no other chance to get it running.
For those guys who have a meter installed I will keep the option to use the private API like before as it is already implemented and working so far. In future version this support might be dropped if solaredge changes the private API again…

BR
Alex

2 Likes

Thanks Alex, I’ve just run some figures and realised that even when using the API calls for BOTH this AND pvoutput (ie. 2x calls) 24/7 it’ll still be within the 300 calls per day; solaredge only seems to update from the inverter every 15mins so no need to query more often than that, 8 calls per hour (4 for openhab, 4 for for pvoutput) for 24 hours = 192 calls, even checking every 10mins is 12x24 = 288 calls

That said, it would be more ideal if an “active time” could be specified to reduce spurious calls. Probably something elsewhere in openhab that can handle that, time for me to do some research…

Has anyone ever successfully communicated with the tech developers at solaredge? Wonder if we (well, Alex) can get any official help?

Hi @roguestreak,

at least for my setup which contains a meter the data is updated quite frequently, I think it is updated once per minute. The graph is of course aggregated at 15min level but the live data is updated more frequently.

@all:
I just pushed the latest changes. The rework is almost complete. It contains the private API (supports only setups with a meter) and the public API (supports setups with and without a meter). If you use the public API (default) the aggregate data is currently not available at week level. I do not understand what the API returns on that aggregation level. The battery self consumption channel is in general not available via public API.

Please take a look at the readme https://github.com/alexf2015/openhab2-addons/blob/solaredge-dev/addons/binding/org.openhab.binding.solaredge/README.md as some configuration parameters have been renamed, added or removed.

For those guys (like me) who have a meter the binding will behave like before if you set

meterInstalled=true
usePrivateApi=true

If you use the public API you will need an API_KEY which you can either generate yourself (if you are site administrator) or it can be requested from the company which installed your solar plant.

BR
Alex

1 Like

@AlexF
Thank you for your effort. I replace the binding and updated/checked all the setting. The (live) production data is being pulled in again and the first look at the debug logging shows no errors on the binding :slight_smile:

Thanks Alex!

I got it installed late yesterday arvo, unfortunately just as the last glimmer of of PV production disappeared so I couldn’t test that, but I did get a daily aggregate figure.

This morning I checked a few things and the logs, and there were some “(COMMUNICATION_ERROR): Too Many Requests”, and I noted that the polling info had “meterinstalled=true”. I’d set the Thing up via PaperUI and had LegacyMode ticked, but thought I’d try removing it all again and trying a file-based Thing, but unfortunately I seem to suck at that and despite seemingly having everything defined correctly I got a “HANDLER_MISSING_ERROR”

So I went back to PaperUI and re-configured, and what I’ve noticed is that if I have LegacyMode turned OFF the resulting polling setup has “meterInstalled=false”, giving me my live production, whereas turning it on results in “meterInstalled=true” and lots of extraneous fileds with zeros, and no production values. I assume this was intended to be the other way around, but it’s fine as is when you know what end result you need. I’m guessing most others don’t suck at file-base Things and that’s why it hasn’t shown up, but something to note when using PaperUI. All of my Items, SiteMaps etc are file-based so not sure where I go wrong in the Thing department.