Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Firmware 1.22.1

This site may earn commission on affiliate links.
did you use the two-step saving of the schedule to avoid the bug
I didn't, no. I've done it now, so we'll see what happens.

That said, when I captured the web traffic that this uses (for my TOU API thread), it was apparent that every change results in the complete schedule (weekend and weekday) being sent, so I can't see why splitting it up should make any difference.

Discharging during off-peak isn't inherently wrong, and the Powerwall doesn't have enough information to determine whether it should do so or not (it would depend on the detailed pricing of the tariff). In my case, discharging during off-peak provides little or no benefit, so I'd prefer that it not do it, but I can't really argue that it's a bug. Charging from the grid, and then discharing during the same tariff band clearly is, though.
 
It's plausible that the server processing of the schedule could have a bug that only manifests when both weekend and weekday schedules are changed, even if both are sent every time the configuration is changed. It wouldn't be hard to imagine that the first step the server does is to compare the new configuration to the existing configuration and then do some processing only if it's different, with the bug being that there is some interaction between the weekday and weekend calculations that causes the actual charging/discharging schedule to be messed up (e.g. a variable that is not reinitialized for the weekend processing after the weekday data is processed).
 
To ensure there's no confusion on this point, I'll mention that https://teg-xxx is only going to work if you're connected via the TEG wifi access point, not if you're connected via your ordinary WIFI. This is because the teg-xxx name is resolved by the name server in the gateway, and that's only used if you're connected to the TEG access point.

Sylvia, that's NOT what the support website states. It gives you TWO options to get to the https://teg-xxx webpage. One, of course, is what you stated - through the local TEG WiFi network. The OTHER is through the WiFi access you specify it go to for WiFi access:

Monitoring from your Home Network | Tesla
 
To All - I have been in many discussions with Tesla support regarding 1.22.1. They do not know themselves what this release was to solve past 1.21.0. I spent three days resetting my synchronizer every morning and finally had it on Friday. My installer came out and we had a long conversation with tech support and I was rolled back to 1.21.0. This is Monday - I have had three full days of GREAT usage of the Powerwall with no resetting or any other glitches. I highly recommend that anyone with 1.22.1 that is having issues insist they be rolled back to 1.21.0 - which is a very stable version for me.
 
  • Informative
Reactions: neroden
I have to give that a try later. What's funny is on that page the Chrome screenshots show them accessing it through the local 192.168 IP address, and the Safari browser shows the teg-XXX hostname.

That's interesting. I've only used Chrome and Internet Explorer on the PC to access the Powerwall - and neither can resolve the TEG-xxx name. I can only access them with the requisite IP address. But see my post from today - I have abandoned 1.22.1 to go back to 1.21.0 as Tesla support has NO idea what 1.22.1 does and I was requiring a reset every day to maintain WiFi access. 1.21.0 is VERY stable (at least for the three further days I've used it over the weekend and the 6 days I used it prior to 1.22.1) and I have not had to reset anything - all the while my router has needed reset for other reasons. It just stably reacquires the IP address and continues to allow me to see the Power Flow on a window on my PC after re-acquisition of the IP address - no resetting of the unit or re-entering the TEG local network to get the WiFi reset.

If you are having success with 1.22.1, more power to you. But at this point I see no reason for that release as it is just a major headache to manage.
 
Under 1.22.1 I'm continuing to see the Powerwall not discharging to supply the house during peak time, and allowing grid draw instead. Yesterday, it did supply the house later in the evening, having misbehaved earlier. So it's clearly capable of doing it still. I can't see how this can be caused by anything other than the firmware.

I'd be interested to know if others are seeing this behaviour.

Sylvia, my suggestion after personal experience is to have Tesla roll your firmware release back to 1.21.0 - it is MUCH more stable for me.
 
One other thing I notice different in this version (from 1.17.2) is that if the Powerwalls aren't turned on, the percentage charge and number of Powerwalls don't show in the app. The percentage now always shows as 0% and the line showing the number of Powerwalls is gone. If I go by IP directly to the gateway, I can still see the charge percentage.

This could've changed in a previous version but I jumped straight from 1.17.2 to 1.22.1.
 
They are physically turned off. I'm still waiting for PTO on my solar system. :(

I have turned them on a couple times over the past month but turned them back off once they were charged.
Good on you. Keep checking it. I heard about a Powerwall in Australia that was bricked because it was left on with the toggle switch but the breaker was off. This was before the house was occupied and it drained itself down to an unrecoverable state.
 
Sylvia, that's NOT what the support website states. It gives you TWO options to get to the https://teg-xxx webpage. One, of course, is what you stated - through the local TEG WiFi network. The OTHER is through the WiFi access you specify it go to for WiFi access:

Monitoring from your Home Network | Tesla

Yes, that's what it says. It doesn't work for me, and I don't see how it could work unless the nameserver is supporting dynamic DNS updates (and if the Powerwall gateway is trying to use it). Many systems won't support that.
 
5.5kW Hyundai MS250 panels (22 @ 250w apiece) with 22 250w Enphase M215 Inverters. 1x Powerwall 2
Model 3: Reserved 4/3/16 online, Ordered 6/26/18. Delivered 8/27/18. Red AWD 19" wheels VIN: 065XXX
Yes, that's what it says. It doesn't work for me, and I don't see how it could work unless the nameserver is supporting dynamic DNS updates (and if the Powerwall gateway is trying to use it). Many systems won't support that.

I actually cannot get the TEG-xxx name to work for either logins (house WiFi or local TEG network). I use 192.168.91.1 for the TEG network and 192.168.1.xx for my house router (I have the actual IP address made somewhat static by assigning the IP address to the MAC address of the gateway (synchronizer).

Tell me, are you having daily success with firmware version 1.22.1? Nothing but issues for me.
 
Yes, that's what it says. It doesn't work for me, and I don't see how it could work unless the nameserver is supporting dynamic DNS updates (and if the Powerwall gateway is trying to use it). Many systems won't support that.
As to how it would work: there are several fairly standard mechanisms for a device to provide its own hostname other than dynamic DNS. First, DHCP can take a client hostname - some routers will add a DNS entry for that hostname on the local network. Second, on Windows networks, Netbios supports peer-to-peer discovery. Third, on Apple networks, Bonjour supports peer-to-peer discovery.

However, the Tesla Gateway seems to be doing none of these right now.

It'd probably also be more useful if the name were "teg," "powerwall" or "powerpack," since those are actually listed in the certificate it's presenting.
 
  • Like
Reactions: eml2
5.5kW Hyundai MS250 panels (22 @ 250w apiece) with 22 250w Enphase M215 Inverters. 1x Powerwall 2
Model 3: Reserved 4/3/16 online, Ordered 6/26/18. Delivered 8/27/18. Red AWD 19" wheels VIN: 065XXX


I actually cannot get the TEG-xxx name to work for either logins (house WiFi or local TEG network). I use 192.168.91.1 for the TEG network and 192.168.1.xx for my house router (I have the actual IP address made somewhat static by assigning the IP address to the MAC address of the gateway (synchronizer).

Tell me, are you having daily success with firmware version 1.22.1? Nothing but issues for me.
I've had 1.22.1 for a bit now and have had zero issues that I can tell. It's charging and discharging as I would expect it to.
 
Subsequent to a discussion on Whirlpool and doing some experiments, I've determined that it is still possible to set the reserve level immediately, if a fresh login is done prior to each attempt. So I've gone back to controlling it directly rather than relying on Tesla's TOU implementation. Still doesn't address the webserver lockup issue, though, and the webserver still fails frequently even when it doesn't lock up.
 
  • Informative
Reactions: NuShrike