Found a new endpoint, but it returns a binary file #51
Comments
|
Nice find! (And nice work on your project https://github.com/darryllee/teslog). Feel free to issue a pull request with what you know so far, I'm sure the rest of the community will be interested and can help learn more. Thanks! |
|
DOH, I just saw you already published a bash script that's far more elegant than mine. I will create a PR for the vitals endpoint I discovered. :-} |
|
I'm taking a look at the binary file output on my powerwall now. It looks like the various serial numbers of the gateway and the battery units are plastered all over this file. So I suggest you scrub those out before posting an example. I don't know if there is some special encoding or not yet. But I suspect that these are key-value pairs and probably some standard format from Redis or something similar. I'll put into a hex editor and see what I can reverse engineer. example: I'm looking at the output in VIM: Line 24: THOC_AmbientTemp is likely the key, and the value is encoded in the hexidecimal value here: ^@^@^@^@^@^@=@ ; I'll need to see the hex values vs the ASCII translation to see if the numbers make sense. These would be interesting to have the values too: Also, setting up a "charge completed" notification would be useful in my automation to then enable charging for the car on those days when I'm making more solar than I can use/store in the powerwall. But it looks like these are broken out for each powerwall (if you have multiples on the same gatway). Powerwall 1: Others: Powerwall 2: This is also interesting: |
|
Ha yes, I just created a PR without including my vitals file because of it contained my serial numbers, and I didn't feel like loading up a hex editor and scrubbing that info. But yes, tons of very interesting info that I've not seen in other endpoints. |
|
Not sure if I'm going the right direction but I'm looking at this: 0x0A (Hex value 0A) plus another hex byte always precedes each Value. (maybe 0x0A indicates the end of the line?) The ! = 0x21 - This looks like a the delimiter for the end of each of the keys. So the hex in between those delimiters should be the value. 0x80 = 128 Does this mean 128.60 °F ? Seems a bit hot. My ambient outside of the chassis is 80.24 °F. Maybe 60 ° C? What are your hex values there? |
Merged. |
|
Here's a bit of data between THC_AmbientTemp! up to " TEPOD: At 2:36PM (ambient temp 88ºF) At 6:06PM (82ºF) At 6:26PM (80ºF) So this seems consistent for end of data: |
|
From user power.saver on the teslamotorclub.com forums:
|
|
I'm power.saver on the TMC forums. Thanks to @darryllee for bringing my post over here. Some additional info on the objects with * after them (text enumerations). The first byte after the * character is the length of the text string, followed by the actual text. That wasn't explained in my post on the TMC forums. |
|
With a little work, I was able to parse out most of the vitals file. Here is the text result. The first column is the number of bytes into the file where the parser found the start of an object. This will probably vary since differences in the text string lengths affects the file size. A new delimiter was found: if a 0 (ascii zero) appears after the object then the value is TRUE or FALSE, and is represented by a binary 1 or 0 in the next byte. I show TRUE or FALSE when this occurs. |
|
Unsubscribe
…On Sat, Aug 7, 2021 at 9:47 PM sean-user ***@***.***> wrote:
With a little work, I was able to parse out most of the vitals file. Here
is the text result. The first column is the number of bytes into the file
where the parser found the start of an object. This will probably vary
since differences in the text string lengths affects the file size.
*A new delimiter was found*: if a 0 (ascii zero) appears after the object
then the value is TRUE or FALSE, and is represented by a binary 1 or 0 in
the next byte. I show TRUE or FALSE when this occurs.
0031 : 1118431-00-J =
00b4 : 1092170-03-G =
0128 : THC_State = THC_STATE_AUTONOMOUSCONTROL
0152 : THC_AmbientTemp = 33.600000
019b : 1081100-79-J =
020b : POD_nom_energy_to_be_charged = 2756.000000
0234 : POD_nom_energy_remaining = 11115.000000
0259 : POD_nom_full_pack_energy = 13707.000000
027e : POD_available_charge_power = 7000.000000
02a5 : POD_available_dischg_power = 7000.000000
02cc : POD_curtailed_charge_power = 0.000000
02f3 : POD_curtailed_dischg_power = 0.000000
031a : POD_est_DC_Bus_Power = -2320.000000
033b : POD_Ibatt = -50.600000
0351 : POD_Vbatt = 46.600000
0367 : POD_DC_Bus_Voltage = 428.100000
0386 : POD_state = POD_ACTIVE
039f : POD_enable_line = TRUE
03b4 : POD_ChargeComplete = FALSE
03cc : POD_DischargeComplete = FALSE
03e7 : POD_PersistentlyFaulted = FALSE
0404 : POD_PermanentlyFaulted = FALSE
0420 : POD_ChargeRequest = FALSE
0437 : POD_ActiveHeating = FALSE
044e : POD_Resting = FALSE
045f : POD_CCVhold = FALSE
0470 : POD_HeatZeroCurrentReg = FALSE
048c : POD_ExtendedCapacityMode = FALSE
04aa : POD_IpcRequestedBusUp = FALSE
04c5 : POD_SelfTestRequested = TRUE
050e : 1081100-79-J =
057e : PINV_EnergyDischarged = 4173130.000000
05a0 : PINV_EnergyCharged = 4827370.000000
05bf : PINV_VSplit1 = 123.300000
05d8 : PINV_VSplit2 = 123.200000
05f1 : PINV_PllFrequency = 59.995000
060f : PINV_PllLocked = TRUE
0623 : PINV_Pout = 2.320000
0639 : PINV_Qout = -0.020000
064f : PINV_Vout = 246.500000
0665 : PINV_Fout = 60.011000
067b : PINV_ReadyForGridForming = TRUE
0699 : PINV_State = PINV_GridFollowing
06bb : PINV_GridState = Grid_Compliant
06dd : PINV_MainRelayState = RELAY_CLOSED
0702 : PINV_NeutralRelayState = RELAY_CLOSED
072a : PINV_Iavail = 32.400000
0742 : PINV_Savail = 7.990000
075a : PINV_Vdc = 428.100000
076f : PINV_HardwareEnableLine = TRUE
078c : PINV_PowerLimiter = PWRLIM_No_Power_Limit
080d : 1092170-03-G =
0881 : THC_State = THC_STATE_AUTONOMOUSCONTROL
08ab : THC_AmbientTemp = 29.100000
08f4 : 1081100-59-J =
0964 : POD_nom_energy_to_be_charged = 2758.000000
098d : POD_nom_energy_remaining = 11207.000000
09b2 : POD_nom_full_pack_energy = 13810.000000
09d7 : POD_available_charge_power = 7000.000000
09fe : POD_available_dischg_power = 7000.000000
0a25 : POD_curtailed_charge_power = 0.000000
0a4c : POD_curtailed_dischg_power = 0.000000
0a73 : POD_est_DC_Bus_Power = -2350.000000
0a94 : POD_Ibatt = -51.200000
0aaa : POD_Vbatt = 46.600000
0ac0 : POD_DC_Bus_Voltage = 428.000000
0adf : POD_state = POD_ACTIVE
0af8 : POD_enable_line = TRUE
0b0d : POD_ChargeComplete = FALSE
0b25 : POD_DischargeComplete = FALSE
0b40 : POD_PersistentlyFaulted = FALSE
0b5d : POD_PermanentlyFaulted = FALSE
0b79 : POD_ChargeRequest = FALSE
0b90 : POD_ActiveHeating = FALSE
0ba7 : POD_Resting = FALSE
0bb8 : POD_CCVhold = FALSE
0bc9 : POD_HeatZeroCurrentReg = FALSE
0be5 : POD_ExtendedCapacityMode = FALSE
0c03 : POD_IpcRequestedBusUp = FALSE
0c1e : POD_SelfTestRequested = TRUE
0c67 : 1081100-59-J =
0cd7 : PINV_EnergyDischarged = 4179150.000000
0cf9 : PINV_EnergyCharged = 4857010.000000
0d18 : PINV_VSplit1 = 123.400000
0d31 : PINV_VSplit2 = 123.100000
0d4a : PINV_PllFrequency = 60.007000
0d68 : PINV_PllLocked = TRUE
0d7c : PINV_Pout = 2.330000
0d92 : PINV_Qout = -0.030000
0da8 : PINV_Vout = 246.600000
0dbe : PINV_Fout = 60.013000
0dd4 : PINV_ReadyForGridForming = TRUE
0df2 : PINV_State = PINV_GridFollowing
0e14 : PINV_GridState = Grid_Compliant
0e36 : PINV_MainRelayState = RELAY_CLOSED
0e5b : PINV_NeutralRelayState = RELAY_CLOSED
0e83 : PINV_Iavail = 32.400000
0e9b : PINV_Savail = 7.980000
0eb3 : PINV_Vdc = 428.100000
0ec8 : PINV_HardwareEnableLine = TRUE
0ee5 : PINV_PowerLimiter = PWRLIM_No_Power_Limit
0f67 : 1118431-00-J =
0fdb : ISLAND_VL1N_Main = 122.500000
0ff8 : ISLAND_FreqL1_Main = 60.010000
1017 : ISLAND_VL1N_Load = 122.500000
1034 : ISLAND_FreqL1_Load = 60.010000
1053 : ISLAND_PhaseL1_Main_Load = 0.000000
1078 : ISLAND_VL2N_Main = 121.000000
1095 : ISLAND_FreqL2_Main = 60.010000
10b4 : ISLAND_VL2N_Load = 121.000000
10d1 : ISLAND_FreqL2_Load = 60.010000
10f0 : ISLAND_PhaseL2_Main_Load = 0.000000
1115 : ISLAND_VL3N_Main = 0.000000
1132 : ISLAND_FreqL3_Main = 0.000000
1151 : ISLAND_VL3N_Load = 0.000000
116e : ISLAND_FreqL3_Load = 0.000000
118d : ISLAND_PhaseL3_Main_Load = -256.000000
11b2 : ISLAND_L1L2PhaseDelta = -256.000000
11d4 : ISLAND_L1L3PhaseDelta = -256.000000
11f6 : ISLAND_L2L3PhaseDelta = -256.000000
1218 : ISLAND_GridState = ISLAND_GridState_Grid_Compliant
124d : ISLAND_L1MicrogridOk = TRUE
1267 : ISLAND_L2MicrogridOk = TRUE
1281 : ISLAND_L3MicrogridOk = FALSE
129b : ISLAND_ReadyForSynchronization = TRUE
12bf : ISLAND_GridConnected = TRUE
12d9 : SYNC_ExternallyPowered = FALSE
12f5 : SYNC_SiteSwitchEnabled = TRUE
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/vloschiavo/powerwall2/issues/51*issuecomment-894742452__;Iw!!IKRxdwAv5BmarQ!MX696kmbCCiWOdDVri9n4kbcZNAfTDfRuzw6YSf3m6zBFGBGfo2OsV01g5ngPg$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABU4JYCDTKZRP35PQGK7GHDT3YD4NANCNFSM5BVJR2CQ__;!!IKRxdwAv5BmarQ!MX696kmbCCiWOdDVri9n4kbcZNAfTDfRuzw6YSf3m6zBFGBGfo2OsV3uEC3dQw$>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!IKRxdwAv5BmarQ!MX696kmbCCiWOdDVri9n4kbcZNAfTDfRuzw6YSf3m6zBFGBGfo2OsV0M-v6DlA$>
or Android
<https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email__;!!IKRxdwAv5BmarQ!MX696kmbCCiWOdDVri9n4kbcZNAfTDfRuzw6YSf3m6zBFGBGfo2OsV3ihpVmiQ$>
.
|
|
Nice work everyone! Thanks! Is anyone up for creating a sample decoder script? |
|
Got new firmware last night (21.31.0), and noticed that the vitals files that I've just been dumping (every 5 min) into a directory was consistently slightly bigger. I did a diff -a and eyeballing it, this is the only thing that I could see that is "new": That's "below"(?) a previously undocumented PVS section. Full dump. Before: After: Yeah... a decoder would be nice. :-} |
|
I've attached the parser I wrote in C. Sample output file included as well. |
|
Awesome! To get it to build on my Raspberry Pi I just had to remove: And flip the slashes here: Then I ran it (so the input file has to be named vitals. Got it.) Do you think those are new delimiters for the |
|
I don't have 21.31.0 yet, so can't check the file, but all others were preceded by 0x12 0x?? 0x0a before the key. 0x?? is any value. So if it follows that format, it should get parsed out. I read all the way to the end of the file. Yes, the input file is called vitals since that's what the PW downloaded, but you could change that in the code if you like. |
|
Would a hexdump help? |
|
The first one is cut off, but the the second one, starting at 0db9 = 12, 0dba = 19 (don't care) and 0dbc = 0a so the parser should find it. The trailing character is "0" so this is a TRUE/FALSE key, and the value is 00 (FALSE). But the next one is different, there are no starting bytes and no trailing delimiter, so the parser won't find that this one (PVS_a019_MciStringC) or the rest of them. Looks like they may be a list with no values? |
|
Sorry, yeah, I cut it off too soon: If I'm reading this right, I think PVS_a031_Mci3PvVoltage and PVS_a031_Mci3PvVoltage both start with: 1a16, and well, then there's a bunch of data after that that I cut off in my last post. Sorry about that. |
|
The 16 is the string length (22 characters). The 1a is unknown because it immediately follows the previous key, which should have been a delimiter and a value, but they are not there. It's possible they added these new keys without fully implementing them, since no values appear after them like all the others. Or they are just text which is part of PVS_StringD_Connected. |
|
I'll just add here that putting my output through a protobuf decoder yields something at least half-way sensible, so this may be a serialization format based on a similar principle. Try this: https://protogen.marcgravell.com/decode The strings and varints seem to decode correctly, but the fixed64 values don't appear correct, so it's probably some other format. In terms of unpacking the data, though, this might be helpful. I'm still on version 21.20.6, FWIW. |
|
Not perfect.. but close. It's definitely protobuf. I am able to parse my file using this but I still have a few defects. The "root" is the DevicesWithVitals entity which contains multiple devices. The c script above was dumping the aggregates across multiple devices. |
|
`syntax = "proto3"; import "google/protobuf/timestamp.proto"; message DeviceVital { message StringValue { message UInt32Value { message ConnectionParameters { message TeslaHardwareId { } message TeslaEnergyEcuAttributes { } message GeneratorAttributes { message PVInverterAttributes { message MeterAttributes { message DeviceAttributes { message Device { message SiteControllerConnectedDevice { message SiteControllerConnectedDeviceWithVitals { message DevicesWithVitals { |
|
Unsubscribe
…On Mon, Sep 20, 2021 at 8:13 PM brianhealey ***@***.***> wrote:
`syntax = "proto3";
option go_package = "github.com/example/path/gen;gen";
package teslapower;
import "google/protobuf/timestamp.proto";
message DeviceVital {
optional string name = 1;
oneof value {
int64 intValue = 3;
double floatValue = 4;
string stringValue = 5;
bool boolValue = 6;
}
}
message StringValue {
string value = 1;
}
message UInt32Value {
uint32 value = 1;
}
message ConnectionParameters {
optional string ipAddress = 1;
optional string serialPort = 2;
optional string serialBaud = 3;
optional uint32 modbusId = 4;
}
message TeslaHardwareId {
optional UInt32Value pcbaId = 1;
optional UInt32Value assemblyId = 2;
optional UInt32Value usageId = 3;
}
message TeslaEnergyEcuAttributes {
optional int32 ecuType = 1;
optional TeslaHardwareId hardwareId = 2;
}
message GeneratorAttributes {
optional uint64 nameplateRealPowerW = 1;
optional uint64 nameplateApparentPowerVa = 2;
}
message PVInverterAttributes {
optional uint64 nameplateRealPowerW = 1;
}
message MeterAttributes {
repeated uint32 meterLocation = 1;
}
message DeviceAttributes {
oneof deviceAttributes {
TeslaEnergyEcuAttributes teslaEnergyEcuAttributes = 1;
GeneratorAttributes generatorAttributes = 2;
PVInverterAttributes pvInverterAttributes = 3;
MeterAttributes meterAttributes = 4;
};
}
message Device {
optional StringValue din = 1;
optional StringValue partNumber = 2;
optional StringValue serialNumber = 3;
optional StringValue manufacturer = 4;
optional StringValue siteLabel = 5;
optional StringValue componentParentDin = 6;
optional StringValue firmwareVersion = 7;
optional google.protobuf.Timestamp firstCommunicationTime = 8;
optional google.protobuf.Timestamp lastCommunicationTime = 9;
optional ConnectionParameters connectionParameters = 10;
repeated DeviceAttributes deviceAttributes = 11;
}
message SiteControllerConnectedDevice {
optional Device device = 1;
}
message SiteControllerConnectedDeviceWithVitals {
repeated SiteControllerConnectedDevice device = 1;
repeated DeviceVital vitals = 2;
repeated string alerts = 3;
}
message DevicesWithVitals {
repeated SiteControllerConnectedDeviceWithVitals devices = 1;
}`
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/vloschiavo/powerwall2/issues/51*issuecomment-923574346__;Iw!!IKRxdwAv5BmarQ!LTuYq4U0-M37z9UhvlyLhI5EqgLPKxRN6t5ooRYeRD7pUn_FKXYz6nePTWtq3Q$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABU4JYGT53TXE3GNAW4TNJTUC7Z65ANCNFSM5BVJR2CQ__;!!IKRxdwAv5BmarQ!LTuYq4U0-M37z9UhvlyLhI5EqgLPKxRN6t5ooRYeRD7pUn_FKXYz6nfBCvfKRQ$>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://urldefense.com/v3/__https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!IKRxdwAv5BmarQ!LTuYq4U0-M37z9UhvlyLhI5EqgLPKxRN6t5ooRYeRD7pUn_FKXYz6ne6enLNpA$>
or Android
<https://urldefense.com/v3/__https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!IKRxdwAv5BmarQ!LTuYq4U0-M37z9UhvlyLhI5EqgLPKxRN6t5ooRYeRD7pUn_FKXYz6nfTWBXPQA$>.
|
|
I logged into my TEG on its internal wifi with installer access. the "System" page shows all the vital statistics nicely represented. The reason I was in there was to figure out how much electricity each solar string was generating. But it would be nice to parse out the additional values like temp and frequency as well. |
|
@sean-user Thanks for your code. I ported a version to python here but it isn't quite right. The @brianhealey Were you able to parse with that? Any quick tips for someone just learning protobuf? :) I just I was able to use protoc --decode_raw < vitals.binIt represents the data in I'm particularly interested in getting power data on strings. This shows up in the PVAC section - example: Boolean examples: |
|
I used the great work by @brianhealey (tesla.proto definition) to process the vitals payload and produce a json representation. Work in progress: https://github.com/jasonacox/pypowerwall/tree/main/examples/vitals UPDATE: I added the protobuf handling to the pypowerwall python library to make it easy to pull the vitals data. My goal was to get the solar panel "String" data so I added a function to parse that data from the vitals payload. Both functions, # Install pyPowerwall package
pip install pypowerwallimport pypowerwall
# Credentials for your Powerwall - Customer Login Data
password='password'
email='email@example.com'
host = "localhost" # Change to the IP of your Powerwall
timezone = "America/Los_Angeles" # Change to your local timezone/tz
# Connect to Powerwall
pw = pypowerwall.Powerwall(host,password,email,timezone)
# Display Vitals (returns details as dictionary or JSON)
vitals = pw.vitals(jsonformat=False)
print(vitals)
# Display String Data
strings = pw.strings(jsonformat=False)
print(strings) |
|
What would be the best way to format the output a bit better? I am Pre-PTO I think there are issues with my MCI - Maybe once a week / day etc. I have to keep an eye on my strings. If getting the fromat correct and comparing it from a baseline everyday if something turns False for a string some type of email notifaction would be amazing for a lot of people I believe when they think there solar is under producing but in the end it could be a MCI problem or a string issue since people complain alot about under performance this could be the reason why! After executing this is what I get for the Dispaly String Data: {'A': {'Current': 1.1300000000000001, 'Voltage': 141.20000000000002, 'Power': 173.0, 'State': 'PV_Active', 'Connected': True}, 'B': {'Current': 0.54, 'Voltage': 339.0, 'Power': 178.0, 'State': 'PV_Active', 'Connected': True}, 'C': {'Current': 0.59, 'Voltage': 324.6, 'Power': 197.0, 'State': 'PV_Active', 'Connected': True}, 'D': {'Current': 0.48, 'Voltage': 99.4, 'Power': 64.0, 'State': 'PV_Active', 'Connected': True}, 'A1': {'Current': 1.1, 'Voltage': 302.90000000000003, 'Power': 327.0, 'State': 'PV_Active', 'Connected': True}, 'B1': {'Current': 1.09, 'Voltage': 303.5, 'Power': 320.0, 'State': 'PV_Active_Parallel', 'Connected': True}, 'C1': {'Current': 0.0, 'Voltage': -1.299999999999999, 'Power': 0.0, 'State': 'PV_Active', 'Connected': False}, 'D1': {'Current': 0.0, 'Voltage': -0.29999999999999893, 'Power': 0.0, 'State': 'PV_Active', 'Connected': False}} |
|
Hi @reli3 - I want to keep an eye on my strings as well, which is why I wrote this. I also wanted to keep an eye on the Neruio solar meter which is also in the strings = pw.strings(jsonformat=True)
print(strings)Output: {
"A": {
"Connected": true,
"Current": 0.48,
"Power": 115.0,
"State": "PV_Active",
"Voltage": 251.8
},
"B": {
"Connected": false,
"Current": 0.0,
"Power": 0.0,
"State": "PV_Active",
"Voltage": -2.3999999999999995
},
"C": {
"Connected": true,
"Current": 1.82,
"Power": 526.0,
"State": "PV_Active",
"Voltage": 293.6
},
"D": {
"Connected": true,
"Current": 1.81,
"Power": 521.0,
"State": "PV_Active_Parallel",
"Voltage": 294.0
}
}I push that into a tiny installation of Splunk (see TinySplunk) and get a graph like this:
I have a lot of trouble with the Neruio solar meter that Tesla installed in my Powerwall+ so I also have scripts to watch that. It shows up in the "NEURIO--VAHxxxxxxxxxx": {
"NEURIO_CT0_InstRealPower": 1333.5606370817025,
"NEURIO_CT0_Location": "solar",
"Parent": "STSTSM--xxxxxxx-00-E--TGxxxxxxxxxxxx",
"firmwareVersion": "1.6.1-Tesla",
"lastCommunicationTime": "1638720520",
"manufacturer": "NEURIO",
"partNumber": "",
"serialNumber": "VAHxxxxxxxxxx"
} |
|
@jasonacox omg thata is amazing exactly what I think I am looking for....any chance for a write up to set this up via tinysplunk on how you are getting the data in? Does it pull the string data every minute? This output will help in the morning and ill run it via cron to put to what I need instead of having to login via installer and flipping the powerwall switch when I think its not producing the correct amount of solar as expected! I loved your other dashboard with grafana was thinking of making a PI display just for that eventually. I believe I have the NEURIO as well since I have Two Powerwall+ and 4x Powerwalls. I haven't had any issues with the Neurio at least so far besides sometimes the inveter likes to discount from the Wi-Fi every once in a while which what I found was to re join it via the App surpisingly and it fixes it. Thanks for your amazing work so far with this! |
|
Thanks @reli3 ! I cross posted this as an issue under pypowerwall for Strings Data- (see jasonacox/pypowerwall#1) since I don't know how relevant it would be for this issue. I included the script I use to gather and push the string data into Splunk. I plan to add this to the Grafana dashboard as well. :) |
|
Glad to see that the protocol buffer example helped. :) There were some errors in what I put together, so I forked your branch to update it. Hopefully this update will help flush out any issues your might be seeing and/or include fields I didn't have before that might be silently ignored. |
https://teg/api/devices/vitals
Good old strings returns some interesting tidbits:
I'd love to get temperature info from my gateway/inverter/battery since I was having problems with my brand-new Tesla 7.6kW inverter because it was installed with low coolant, and until it got topped off last week, was throwing "Inverter Over Temperature" alerts (which after a recent update, were only visible after logging on as Installers instead of Customers. Super-shady.)
The text was updated successfully, but these errors were encountered: