please provide log output.
Aggregate data should either be there for both daily and weekly aggregation levels or not at all.
The token has a limited lifetime which is something about 50 years. As it is used for both live and aggregate data retrieval it seems to be valid in your case. An invalid token would cause the binding to switch to offline.
in the last image after reboot its always diffrent which items come back and which dont. events.txt (44.1 KB) openhab.txt (69.8 KB)
note.
i have also tried a new install of openhab with only the solaredge binding installed. still same issue with it.
install binding everything ok. reboot parts go missing,
I can see a lot of error which belong to the MQTT binding. And also a lot of errors which come from solaredge binding because MWh is not recognized as a unit that is supported. The type conversion error should not cause the loss of items.
As you mentioned that you also tried a fresh install with only solaredge installed I really do not have any idea. No one else has reported such issus so I guess it is specific to your setup.
i have tried on windows and on rpi3 B. (windows 2.5m, rpi3 b with 2.4 and 2.5m).
as you probs worked out from the log im was trying with private key and with meter on.
but every time i have tried its done that. it most likly im not setting it up right but im not sure what i did wrong.
I am using this binding since beginning this year and would like to thank all who made this binding possible.
For now I want to share the following.
Beginning Augustus the “year production” showed some strange dips and spikes in my graphs. This was not the first time but this time I contacted the Solar Edge Supporteam.
After some misunderstanding, like caused to cloudy weather, Solar Edge updated the firmware of the inverter as solution. Did it fix the problem? Perhaps, installed a rule to monitor future strange behaviour easier.
Feel free to check if this behaviour is also visible in your sytem and if your firmware is up to date.
My details are (right click in menu option “layout” on the inverter, unless you are a lefty):
Hello and thank you for the SolarEdge binding that keeps pushing data nicely into my Raspberry incl Grafana&Influxdb.
Being still very new to openhabian 2.4.0.1 stable, I would now like to make the next step and go from “monitoring” to “automation”.
This is my setup:
Release = Raspbian GNU/Linux 10 (buster)
Kernel = Linux 4.19.57-v7+
Platform = Raspberry Pi 2 Model B Rev 1.1
The idea is to check for any excess power (by looking at the “export”-channel) and switch on an electrical heating device (using the shelly plug binding), if the export to the power grid is exceeding 600 Watts.
If the import from the power grid is greater than 0 Watts, the heating should turn off ASAP.
This shall secure that only excess renewable energy will be used for heating.
I managed to switch the heating device (using shelly plug s) without problems, however I am having difficulties with the syntax for the “if”-clauses on the solaredge devices.
I have tried
rule "Handtuchwaermer_an"
when
Item solaredge_generic_373357ff_live_export changed
then
if(solaredge_generic_373357ff_live_export > 0.6){
shelly_shellyplugs_79a136_relay_output.sendCommand(ON)}
end
rule "Handtuchwaermer_aus"
when
Item solaredge_generic_373357ff_live_import changed
then
if(solaredge_generic_373357ff_live_import > 0.0){
shelly_shellyplugs_79a136_relay_output.sendCommand(OFF)}
end
…however logviever complains about
2019-11-06 22:56:09.525 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'Handtuchwaermer_aus': Unknown variable or command '>'; line 15, column 13, length 44
I hope I am asking in the correct place… this is the first rule that I am creating, so I guess I am missing something here?
Can someone guide me to the correct syntax, please? Any guidance or hints are greatly appreciated.
can someone give me an understandable tutorial/ link/ hint on how to use a private API?
edit: i solved it by myself. You guys have to readout the cookie information of the solaredge monitoring website and search for the string provided in the doc. Entering this in the binding config will enable using the private API.
But neither with private nor with official API i can get any aggregated data at all…
I hope this question is not sounding too stupid for the experienced guys around here, especially AlexF.
I am still running this binding nicely with both “ModBus Meter” and “Private API” toggle switch activated. As per my current understanding this shall be enough to avoid running into 300-requests API-limitation (as all data can be obtained locally).
What I do not understand (here comes my question):
Despite me being on a truely local datasource, I still can not go below a value of 1 request per minute, as this is the absolute minimum setting allowed for the binding.
How is it possible to let this binding utilize “realtime” data (that I can see in the cellphone app)
for OpenHAB as well and benefit from “live”-data?
This is the maximum update frequency (–> 1x per minute) I can currently get successfully from this binding:
2020-10-13 14:44:17.793 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 2.98 kW to 2.89 kW
2020-10-13 14:45:18.206 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 2.89 kW to 2.97 kW
2020-10-13 14:46:17.865 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 2.97 kW to 2.98 kW
2020-10-13 14:47:17.875 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 2.98 kW to 2.91 kW
2020-10-13 14:48:17.859 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 2.91 kW to 3.0 kW
2020-10-13 14:49:17.889 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 3.0 kW to 0.91 kW
2020-10-13 14:50:17.958 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 0.91 kW to 0.9 kW
2020-10-13 14:51:17.864 [vent.ItemStateChangedEvent] - solaredge_generic_373357ff_live_consumption changed from 0.9 kW to 1.65 kW
Any hints for to increase the logging frequency to “live”/“realtime” (or at least every 10 seconds or so) would be highly appreciated, as this would allow to react faster on changes (increase/decrease of power consumption, clouds appearing etc) and trigger associated rules in OpenHAB more targeted and precise.
I believe the for real-time updates, you need to plug an Ethernet cable directly into the inverter and use the modbus binding. It’s on my list of stuff to do but need to drill through a garage wall first…
I was hoping that there would bei a solution based on this binding … Not sure if that ist a technical feasible option? I thought there could bei a way to decrease the minimum update intervall from 1 minute to 1 second or something simple like that?
Maybe (one of) the author(s) of this binding can shed some light here…
If possible I would prefer to stay with this dedicated SolarEdge binding.
I had this “issue” with the thing status showing “waiting for API web login” some times ago.
Normally it switches to “Status: ONLINE logged in” after some seconds/minutes.
In the meantime it is already working.
The binding relies on the data retrieved from SolarEdge Cloud. In case of using the public API there is a very strict limitation regarding requests per day. In case of using the private API this limitation is bypassed. But still the update frequency is limited as the cloud storage is not updated in real time.
I limited the update frequency to 1 minute as this will not cause excessive load on the Solaredge servers. If too many people make use of a very short frequency this might cause significant load which will definetly be investigated by Solaredge and most likely result in some change of the API to lock out unofficial users like my binding.
I believe it should technically be possible to retrieve updated data every 10 or 20 seconds as this is the frequency of updates in the APP. For true real time updates it would be necessary to enable Modbus over TCP in your inverter and use the Modbus binding to retrieve the data. But that is much more complicated as the modbus binding is very generic and thus everything is a little bit more “raw”.