I just installed this to query my Powerwalls and it is working fine.
I'm really trying to solve a particular problem: I'm not getting Tesla notifications when the grid goes down (some software issue on their end), so I'm trying to work around that.
I want to query the Powerwall and check for Grid Status, and use that in a rule to raise a notification via Hubitat when that happens.
I was going to write something that just queried that one REST API (/api/system_status/grid_status based upon vloschiavo/powerwall2), but then I thought there might be something that already does this. And so I found this.
So I see the state I want to trigger on... but how to I access it from RM?
There should be an Event for it also, which means you can check for the "Grid Status" attribute of the device in RM. In the Trigger Events section you would select Custom Attribute then select Grid Status from the list.
All boolean attributes have been replaced by strings. I was informed that boolean attributes are not a valid type and it was discovered that this caused an error with some apps. While they display and appear to work just fine (and cause no other errors) I do try to follow what is allowed. So I have gone through and attempted to catch every instance in both drivers.
Changes to the logging and update check methods I use based on lessons learned over time since these were last updated.
My powerwall is installed but not yet commissioned.
The IP I use is the address to login to the gateway. The script can't connect, which may be expected, but it's not handling the error well:
[dev:221]groovy.lang.MissingMethodException: No signature of method: user_driver_Snell_TeslaDriver_488.ParseSitemaster() is applicable for argument types: (java.lang.String, java.lang.String) values: [System Status, Not Up] Possible solutions: ParseSitemaster(java.lang.Object, java.lang.Object) (ParseSitemaster)
[dev:221]Powerwall - Unhandled data: power_supply_mode = false
[dev:221]Powerwall - Error connecting to Tesla for Powerwall(s). 424
[dev:221]Powerwall - Error connecting to Tesla for Aggregate. 502
[dev:221]Powerwall - Error connecting to Tesla for System Status. 502
[dev:221]Powerwall - Error connecting to Tesla for Grid Status. 502
[dev:221]Powerwall - Driver version up to date
I am not sure what you mean by commissioned... I do not have a Powerwall so I am not familiar with how it all works (I did the driver for the sheer sake of being helpful and with lots of samples and understanding from @jared.zimmerman and @scottgu3). But the IP/Hostname should be for the Powerwall's gateway (you can validate it using a browser apparently per Tesla's instructions).
Not sure why there is a "MissingMethodException" but I will have to look at that, I probably need to build a check if it fails to connect or something like that.
The other errors are because I have never seen a 502 error before (on any of my drivers that I can think of) so I do not have any specific error or such for it, it just falls back to the default of "Error connecting..." with the unknown error #. I looked it up and a 502 is a "bad gateway error". Not sure there is much I could do about it EXCEPT be more specific for it.
There is also a new piece of data that I had not seen in any of the previous samples, thus the Unhandled data of "power_supply_mode = false". So I will have to build that in as well in an updated version.
As I recall, "commissioned" is what happens when the system is formally connected to the Grid. Until it's commissioned, the system remains "offline" and will not produce power. Has to do with the grid-tie and the Smart Meter. The local power company/authority has to sign off on the connection and whatnot before Tesla can turn the system on.
Yes. Although physically connected, I have no control over the powerwall's settings until the installer links it to the right Tesla servers.
I believe it's actually charged and configured for 100% backup, so I get some benefit if the power goes out, but it doesn't become mine until all the inspections are passed and they turn it over.
But I would think it would still show up "something" if it is on your network. Does the webpage that Tesla provides for it show anything useful? It may just be that everything is blocked until it is officially commissioned (and that might be why there is that unhandled data, that might be the only response in that stage). I guess I can just add some to the driver that if it gets a 502, it is not yet "ready" so do not try all the other checks until it comes back successful.
kindof. The default web page just shows the login for the installer/customer to configure IP address for wifi.
I do get some info back from other links:
/api/powerwalls returns
{"code":424,"message":"No system details, please run enumeration"}
/api/meters/aggregates
no response
/api/customer/registration
{"privacy_notice":null,"limited_warranty":null,"grid_services":null,"marketing":null,"registered":false,"timed_out_registration":false}
/api/system_status/grid_status
no response
/api/sitemaster
{"status":"StatusDown","running":false,"connected_to_tesla":true,"power_supply_mode":false}
/api/system_status/soe
no response
/api/site_info
{"max_system_energy_kWh":0,"max_system_power_kW":0,"site_name":"Home Energy Gateway","timezone":"America/Los_Angeles","max_site_meter_power_kW":1000000000,"min_site_meter_power_kW":-1000000000,"nominal_system_energy_kWh":13.5,"nominal_system_power_kW":5,"grid_code":{}}
Adding that I think this situation would be very rare for a system to be un-commissioned for any period of time. My installers f'ed up the main panel upgrade that was required to accommodate the tesla systems, so it's failed city inspection 3 times and still isn't right, but everything is kindof online.
1st inspection (virtual), inspector wouldn't even look at it because of a paperwork error.
2nd inspection (virtual), inspector failed it and needed it to be rescheduled for physical inspection.
3rd inspection (in person), inspector failed it because the main panel wasn't correct.
Even if it is rare, I always want to try to make my drivers (any of them) as encompassing as possible. It looks like I might need to make it so it tests the registration information first or such to check for this scenario. Hopefully I will get a chance over the next few days. I will (of course) post here. So if for some reason they do not have it fixed for you by then, maybe you can check it out.
Seems consistent with my experience. Mine had a ground tie fault in the main panel. My installation experience was a comedy of errors. None of the three "teams" talked to one another -- a beautiful system hampered by a poorly integrated installation process!
I'm guessing by now you may have found out but the reason your driver stopped working is that a recent PW firmware update went out. You now need to authenticate to get any of the data (ie aggregates) so will need to include your token when you request that data. Perhaps that is the issue here?
Not sure my driver is not working (I do not have a Powerwall myself). I heard the app out there based on an ST one is not working... but @scottgu3 said he is still good.
@tomuo16103: Did they ever finish your Powerwall and is the driver working for you now?
