photogeek54

v1.1.02 is now correctly published in the non-production store, fixed problem syncing to github. @Mecheng70's problem adding nodes due to an illegal character in the site name appears to also be fixed.

Just figured it out. it's my problem. Fix coming soon.

So I've reproduced @Mecheng70 issue of not being able to load the current version of solaredge from the non-production store. I deleted my own v1.1.01 NS and tried to reinstall it and now I can only get v1.1.0 even after restarting PG3X and the admin console. There are some errors showing in the PG3X log if that has anything to do with it. error: IoX Response: [Try: 1] [00:21:b9:02:60:68] :: [404 - OK] :: 43.417083ms - http://127.0.0.1:8080/rest/nodes/n005_controller 6/21/2023, 23:11:20 [pg3] warn: node controller on profile 00:21:b9:02:60:68/5 not in the database. Adding... I also see in @Mecheng70's log that he has 2 controllers showing up. Deleting a NS should make those go away. Assuming that his issue not adding the nodes has to do with the "/" in his controller name, then getting him (and me now) to the current version should help. Seems like some kind of PG3X issue and I have the latest IOX and PG3X. I'm hoping @bpwwer has an idea.

Have you tried installing the solaredge NS into 2 different slot #s with a different api key in each?

v1.1.01 of Solaredge should take care of the "/" problem but that version won't load for @Mecheng70. Also attached is the log from the node server. debug.log

Solaredge node server v1.1 is now in the non-production store for your testing. v1.1 adds API rate limiting due to Solaredge 300 API call per day limits. If you set short poll to 60 (sec), for example, the "since last update" field will update every 60 sec to more accurately show you how stale the measurements are but still not exceed the Solaredge daily limits. This is especially helpful if you are logging measurements to a file so you can later see if any measurements are stale. To set an API rate_limit other than the 5min default, enter a new "rate_limit" parameter (in minutes) in the custom parameters and save changes. If you exceed the daily API limit or the solaredge server is overloaded you may see "since last update" exceed the rate limit. Check it out and let me know if you have any issues.

solaredge node server v1.1 is now in the non-production store for your testing. v1.1 adds API rate limiting due to Solaredge 300 API call per day limits. If you set short poll to 60 (sec), for example, the "since last update" field will update every 60 sec to more accurately show you how stale the measurements are but still not exceed the Solaredge daily limits. This is especially helpful if you are logging measurements to a file so you can later see if any measurements are stale. To set an API rate_limit other than the 5min default, enter a new "rate_limit" parameter (in minutes) in the custom parameters and save changes. If you exceed the daily API limit or the solaredge server is overloaded you may see "since last update" exceed the rate limit. Check it out and let me know if you have any issues.

Steve, Sorry for the delay, looks like I was not "following" this topic. There were minimal changes to v 0.2.061. I've just finished a major update that adds rate limiting to better control the API calls so we don't exceed the 300 calls/day limit set by Solaredge. You will be able to set the short poll to a much shorter value (say 60 sec or even 10 seconds) so the "since last update" time shows more accurately. As soon as I solve a bug getting it into the non-production store you can try it out.

Great @stevehoyt We weren't sure it handled multiple batteries correctly.

I have had this problem with entry/access being missed as well. I’m on the latest iOS. I need to do a better job looking in the logs but I suspect that I my phone is missing these events purely because there’s a problem with the cell service signal. Is there a way to check the actual location once in a while rather than just geo-fence crossings from the OS? that way if a poor signal caused a miss eventually it would look up my location and realize it was missed.

That would be great! It’s in the non-production store

Great! Glad it’s working for you. This was my first python program, I wouldn’t have known where to start without leveraging @xKing’s code. There are some good reference documents highlighted by @bpwwer in the developer tab of the pg3 web page but I don’t think you will see those unless you’ve signed up to be a developer. if you don’t see anything in the consumption field, it must mean your inverter doesn’t have consumption monitoring installed. Some installers seem to make this an optional service. Consumption shows how much power your home is using.

Great! I’m hoping to find some users that have other devices like batteries, 2nd inverters, etc to test it too.

I have an extended version of the solaredge node server in the non-production store and it has pretty reliably been able to get updates from my solaredge every 5 minutes.

OK @Ross, solaredge_poly v0.2.05 is in the non-production store. Let's see if I got it right this time. Thanks for finding my mistake Bob.

Ahh, that makes sense, I’ll fix that soon.

So the error here looks quite different than what you saw on your Polisy. python3: can't open file '/var/polyglot/pg3/ns/0021b90243ab_9/./solaredge-poly.py': [Errno 2] No such file or directory it’s not even finding the main python program. Were you able to resolve the problems @bpwwer found on your polisy? I would try to get it working on the Polisy first.

@ross You should stop your existing solaredge running in slot 9 when testing this one but I don't think that's the problem here. I'm running on an Eisy with polyglot 3x, what are you running on? I cannot test this on other hardware I don't understand some of the error messages, here's a snippet from the log. @bpwwer might have some insight. 4/27/2023, 22:21:18 [pg3] error: No code in error response 4/27/2023, 22:21:18 [pg3] warn: ISY Response: [Try: 3] [00:0d:b9:53:36:80] :: [401 - OK] :: 11.074801ms - http://192.168.1.6:8080/rest/profiles/ns/0/connection 4/27/2023, 22:21:18 [pg3] error: No code in error response 4/27/2023, 22:21:18 [pg3] error: ISY Response: [MAX TRIES EXCEEDED] [00:0d:b9:53:36:80] :: [401 - OK] :: 5.655184ms - http://192.168.1.6:8080/rest/profiles/ns/0/connection 4/27/2023, 22:21:19 [pg3] info: ISY node server user configuration update required 00:21:b9:02:43:ab vs 00:0d:b9:53:36:80 4/27/2023, 22:21:19 [pg3] error: Error: GET http://192.168.1.6:8080/rest/profiles/ns/0/connection Failed :: 401 - OK 4/27/2023, 22:21:19 [pg3] error: getExistingNodeServers :: Error: Received no response from the ISY. Check your ISY IP Address at Object.getExistingNodeServers (/var/polyglot/node_modules/@universaldevices/pg3/lib/modules/isy/system.js:91:13) at runNextTicks (node:internal/process/task_queues:60:5) at listOnTimeout (node:internal/timers:533:9) at process.processTimers (node:internal/timers:507:7) at async /var/polyglot/node_modules/@universaldevices/pg3/lib/services/isy.js:80:21 at async Promise.allSettled (index 0) 4/27/2023, 22:21:19 [pg3] warn: verifyNodeServers (00:0d:b9:53:36:80) :: ISY has no node servers installed, skipping

@Ross This is my first node server so thanks for helping me troubleshoot these new issues. When I've seen issues like this I found additional information in the PG3 log. You select "log" at the top of the PG3 web page. See if you see some errors there and send them to me.

Just changed it to active

@RossNot sure why it went away, I just re-submitted it

@ross I've worked on an extended version of solaredge that adds the features you were asking about. Its currently in the non-production node server store if you'd like to try it out. It will likely get more changes before its production ready.

I've discovered that the solaredge API is rate limited to 300 requests for each specific API call per day. SO I assume my issue was caused by too many requests in a day. Given that the values returned by the API only change on 15 minute boundaries. There is no sense setting your short_poll or long_poll intervals to less than 900 seconds. It would be best to send your first request shortly after 0,15,30, or 45 minutes into the hour to be best aligned with the most recent data.

Great idea, I made the change! Thanks.

PLEASE give us notice before causing an Eisy to reboot! A reboot is not temporary for me, all my programs cease to run following a reboot until I set a state variable. This was done as a safety measure to insure a way to access Iox in the event of an infinite loop.