@snell are you calling this "good enough for now" ? completely fine if you are, wondering if you could add in Hubitat package manager functionality for auto updating going forward and I'll mark it as done on the Code bounty $$$ list 
I guess the bigger question is for you two. As the only people that appear to be using it, is it doing what you need it to? Are there features you would like that it is missing (besides Package Manager functionality)? The couple attempts at API access appear to have failed so I may just "rip that out" and call it close enough unless there is more you two would like.
As for Package Manager... UGH... I have looked at that a couple times. In my mind it is annoying. Extra steps, ANOTHER app on my PC (even if it is just a little one it says), more stuff I need to remember every time, and of course I cannot stop doing everything I do now... and I am personally not interested in it so it really does not benefit me either. Heck, I built update notifications INTO my drivers since day 1 (not this driver, my first one) and have refined it over the year+ of driver work. So to toss out a lot of that... Plus end users will have to add MY custom repository to their list, so I do not know that it helps make it much simpler than adding the regular driver and importing once in a while. I just do not know. I have seen this same request on a couple of my other drivers also... so I would have to change ALL of them... otherwise I am not consistent. Sorry... there is even more to it in my mind but I really just do not know yet.
1 Like
@snell Honestly, it does everything I need it to. I need to write some rules to monitor the grid and solar generation, but that's sort of a node-red effort for the future. Right now, this is perfect.
HPM is a nice to have, but hardly critical. Sine this is done for the most part, i don't think its going to be horribly onerous for me to check the git hub occasionally and hit "import" 
Thanks for building this! I appreciate it!!!!
Scott
1 Like
I guess part of my question is "why Package Manager"? I have never really felt the need to use it... the few drivers I use (outside of my own) I generally only check for an update if there is a problem. My own (well... that is cheating) but they have an Event to tell me an update is available. I hardly use any apps at all (outside of Rule Machine and the Broadlink RM setup app) and it really seems geared for an app that has a lot of side extra parts to it.
Not being argumentative at all, I just want to know, because I personally do not feel the need. But obviously there is a place or else they would not have made it and people would not be using it. Trying to figure out if I am on the side of "not really for me" or "fuddy duddy just not using it yet".
Its doing everything I need right now, I'm sure as I play with it more i'll come up with some more things I'd like, but very happy with what's going on now.
HPM, partly laziness, I have a feeling you might come back and tinker with things, and I'd like the confidence that the code i have is up-to-date, also as someone who is still new-ish to hubitat, there were so many things that were hard to find because they were buried in the forums, having thing in HPM made it easier to find things in my mind.
you mentioned that people would have to manually add your repo? but I see new ones added to HPM all the time that I didn't add, the list just keeps getting longer, I'm sure its work on your end to set that up though?
I will have to think about the charity... But I will put version 1.0 tonight or, worst case, over the weekend. I want to remove all the API portion for now to make it more streamlined.
UPDATE:
Version 1.0.0 "Release" is now posted for both the TeslaDriver and TeslaChild. I removed all the API "stuff" I could spot from the TeslaDriver and tried to streamline it a bit as a result. The Child really only had the version changed.
As usual, if anyone spots any bugs, let me know and I will correct it. Still debating about HPM. I will probably give it a try over the weekend.
2 Likes
Getting this error on occasion now
dev:7052020-06-18 11:59:51.506 pm errorTesla Powerwall - Failure to add site and post Instant Total Current=0
dev:7052020-06-18 11:59:51.490 pm errorTesla Powerwall - TeslaChild driver is not loaded, this is required for child devices. Disabling children for rest of refresh.
Neeeeever mind, looks like I had a driver version mismatch.
Glad it worked out.
Anything else lately? It is weird to me to have a "released" driver. Even my oldest ones I still consider in progress... although I guess I could probably "finish" a couple of them.
1 Like
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.
1 Like
Glad to help.
1 Like
Updated Version(s):
- TeslaDriver.groovy = 1.0.1
- TeslaChild.groovy = 1.0.1
Change(s):
- 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 dateI 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.
S.
1 Like
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.
