No RS-485 communication to TWC Gen3 #292
Comments
|
Just to check - you've got a Gen 3, so it had only one pair of RS485 terminals and you did the setup via wifi rather than rotary switch? |
|
So I connected the Raspberry Pi with Ethernet. Didn't set up anything with the wifi, thought the communication happens purely via RS-485. What do you mean with rotary switch? It only has got the RS485 pins.. |
|
Well, unfortunately the Gen3 TWC isn't supported at all. I'm trying to work out if it is a Gen3 TWC. If you followed the install instructions you would have run into a few issues - there should only be 2 RS485 pins rather than the 4 show in the installation docs, and there shouldn't be a rotary switch (as the Gen3 is setup via wifi and not via a physical switch). If that's the case, I'm afraid your Gen3 doesn't have load sharing capabilities yet - I am hoping it will do eventually - and isn't supported. |
|
Thank you for your quick response. But should I then be able to see and control the TWC via Wifi on the TWCManager? |
|
That's what we'd like to be able to do as well, but unfortunately the Gen3 is a closed platform and we have very little info about it. There are only a few exposed endpoints currently over wifi and they don't do much. From all the info I have, I don't think the Gen3 will be controllable until a future Tesla firmware update is released: |
|
Okey thats to bad, What for expodes endpoint did you get? It's a pity that it cannot communicate with the RS-485 interface. |
|
So far all I am aware of is:
http:///api/1/version
http:///api/1/vitals
http:///api/1/wifi_status
http:///api/1/lifetime
If we do come across anything interesting I will start integrating it, but
from the above there only seems to be a lifetime kWh counter that I could
grab
This thread has more info:
https://teslamotorsclub.com/tmc/threads/gen3-wall-connector-api.228034/
If you could send me the output of the /vitals API endpoint on your TWC I
could see if it has anything useful... Unfortunately Gen3s aren't available
in my country yet so I can't get one to play with
…On Fri, 28 May 2021, 22:05 mare1901, ***@***.***> wrote:
Okey thats to bad, What for expodes endpoint did you get? It's a pity that
it cannot communicate with the RS-485 interface.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#292 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGFF33CKU22VQU4PRUSHDSDTP6BJJANCNFSM45WELWWQ>
.
|
|
Here is my Output of the /vitals API: {"contactor_closed":false,"vehicle_connected":false,"session_s":0,"grid_v":232.0,"grid_hz":50.020,"vehicle_current_a":0.4,"currentA_a":0.2,"currentB_a":0.4,"currentC_a":0.2,"currentN_a":0.3,"voltageA_v":0.0,"voltageB_v":4.9,"voltageC_v":0.0,"relay_coil_v":12.0,"pcba_temp_c":29.0,"handle_temp_c":22.1,"mcu_temp_c":34.9,"uptime_s":190,"input_thermopile_uv":-204,"prox_v":0.0,"pilot_high_v":11.9,"pilot_low_v":11.9,"session_energy_wh":0.000,"config_status":5,"evse_state":1,"current_alerts":[]} |
|
If you want we can configure a connection to our System with a VPN. Than you can play with the TWC Gen3 |
|
I will start to take a look at Gen 3 shortly, to see what is or isn't possible, just give me a little time to fix a few high priority things and I'll make a start, and I'll let you know what I need in terms of output from your TWC. At very least I can have it appearing in the UI and reading the status to start with, but not sure about controlling the charge rate, let's see what we can find in the APIs. |
|
Any news here? I have one too, can confirm that /api/1/vitals responds current charging data, even session energy consumption. the currents are correct, all good. |
|
Interesting note: {"wifi_ssid":"ZnVua25ldHp3ZXJr","wifi_signal_strength":36,"wifi_rssi":-72,"wifi_snr":22,"wifi_connected":true,"wifi_infra_ip":"192.168.178.61","internet":true,"wifi_mac":"98:ED:5C:8C:FD:50"} |
|
for reference: this is my model 3 charging at 16A/400V (11KW) /api/1/vitals {"contactor_closed":true,"vehicle_connected":true,"session_s":2384,"grid_v":226.0,"grid_hz":49.885,"vehicle_current_a":16.1,"currentA_a":16.0,"currentB_a":16.0,"currentC_a":16.1,"currentN_a":0.3,"voltageA_v":231.2,"voltageB_v":226.7,"voltageC_v":227.6,"relay_coil_v":6.1,"pcba_temp_c":42.7,"handle_temp_c":32.5,"mcu_temp_c":45.3,"uptime_s":8088,"input_thermopile_uv":-848,"prox_v":1.9,"pilot_high_v":0.1,"pilot_low_v":0.1,"session_energy_wh":1969.000,"config_status":5,"evse_state":11,"current_alerts":[]} this is idling after charging finished at 85%: |
|
another find: when doing a GET-Request to /tedapi/v1 it fails with an WSGI Error. |
|
I've had a look through the firmware and it looks like
If you're seeing a WSGI error, it might be a websocket endpoint @pkirchner. Perhaps a streaming API that provides the realtime values from the TWC? There is also this clue in the firmware about what the din endpoint might be for: In terms of other (non /tedapi) endpoints, I see the following:
Some interesting food for thought. Tesla just introduced the sharing feature, which is likely why there's an SSID in the wifi_status output. The TWC v3 version of sharing uses mesh wifi, so likely what happens is you set up the initial unit and then all the other units connect to its wifi SSID and configure sharing that way. What I'm not sure about is how TWC v3 units make the initial connection to fetch the SSID details - unless the SSID is in some way static and so they already know the SSID and key values? I don't have a TWC Gen 3 so I need to hear from someone who does have sharing enabled, but it does sound feasible that once we work out how they do it, we could possibly emulate it ourselves with an SSID and an endpoint with whatever sharing protocol the Gen3 is using. |
|
I've started the following tracking of what we know about the Gen3 and approaches to support it. Really appreciate your input @pkirchner and would appreciate your help with any input as well. I think there's a number of directions we can approach this from, but I am also aware from poking around in the firmware that it's pretty sparse, I am not sure there is a lot there yet to hook into, but if we can document the various different endpoints and their input/output parameters we'll soon be able to progress https://github.com/ngardiner/TWCManager/blob/main/docs/Gen3_Status.md |
Note that I haven't seen any support for multi-connecting a Raspberry Pi's WLAN interface, so this presumably means adding a Wi-Fi dongle to the Pi. This thread suggests netplan is the best way to push separate config to the two interfaces. I'm not sure what netplan exposes for AP mode, but it hopefully exists. |
This is a good point, that was working on an assumption that it was supported but it may well not be. It's probably not too bad of an outcome even if a dongle is required, we require one for RS485 today, but it would be much cleaner if the inbuilt controller could handle multi SSID. |
|
All of this assumes that we aren't locked out of the walled garden by some sort of enrollment process or proprietary protocol usage - it may end up being entirely infeasible. |
|
Seems like "power sharing" is now part of the latest firmware: https://www.tesla.com/support/gen-3-wall-connector-power-sharing So maybe there is hope :) |
|
Of particular note on that page:
"Not currently" suggests it's contemplated in the future. But regardless, if we can spoof the lead TWC, we'd be in business. |
|
The sharing that they have enabled is the wifi mesh sharing, which does not use the RS485 communications bus and as @MikeBishop mentioned, is not compatible with the Gen2. There certainly is hope, but unfortunately this release does not give us the sharing protocol we've been using on Gen2. |
|
Fogetaboutit ;-) On the other hand: there is a RFID-antenna on that LED-strip/RFID Flex-PCB [1470138-61-D] ? |
|
Also while there is no RS-485 it may be possible to "just join" the wifi mesh to co-ordinate. That said for this we would need to know what kind of protocol is spoken there |
|
Ouch - I wonder why they claimed possible future compatibility with Gen 2. Anyway, if it's air gapped we need to give up on RS485 connectivity. |
|
Regardless, given that the previous Gen3s had only one pair of terminals rather than two, I stand by the theory that if they enabled Gen2 integration, it would be master-only. (So a Gen3 could join the mesh and report that it had two Gen2s under its control, so count it as three stations.) Obviously, if they're dropping the remaining pair of terminals, they've decided not to go that direction. Regardless, I think our only path to controlling a Gen3 was always going to be Wi-Fi. Next question is whether the communication is secured in a way we can spoof and what protocol they're speaking. |
|
I have a pair of Gen3 units to charge one Model 3. Will update their firmware and setup power sharing, and will report values when querying the listed endpoints. How are you querying these endpoints and reading their response values? Via a browser, or curl, or something else? |
|
Thanks for that! Via browser is fine, it will give you a text result that is useful to us for working out what's happening. One other thing that might be really useful - any chance you could run a wifi analyser around the TWCs to see if you pick up the mesh wifi SSID? Something like https://www.nirsoft.net/utils/wifi_information_view.html on windows (or a similar app on smartphone) would be really helpful to compare what you see to the output of the API calls. |
|
Sure, I will use MacOS's WiFI diagnostic tool (or an iOS app if you point me to one). |
|
Is there any chance to turn off and on the charging over the wifi trough the Raspberry Pi? |
That's really what we hope to establish. It may not be possible with just rpi hardware, it may need an additional wifi radio. Let's see what we find. |
|
Hello Nathan @ngardiner, may I kindly ask for update regarding plans for TWC Gen 3 support on TWC Manager and your thoughts about possibility of Gen 3 and Gen 2 interoperability. Would it be please possible to update: https://github.com/ngardiner/TWCManager/tree/main/docs/Gen3_Status.md I just need to obtain another TWC to my current primary TWC Gen2 and want to be sure that I have to go again for Gen2 or if Gen3 has future potential with TWC Manager. |
|
There is no update unfortunately. I have no Gen3 myself and no plans to get one given the price and general unavailability, but I would gladly accept patches from someone with one who gets it working. Note that due to Tesla disabling RS485 in the Gen3s at this time I suspect the only way to make it work would be via the WiFi, so it is no trivial task to link it in with a project that is entirely based around RS485 comms. I've had offers to have access to others' units but I won't be taking those up, unfortunately I'm chronically under resourced when it comes to free time and you can't just hack hardware remotely. If you do get a Gen3, sadly TWCManager won't be able to help with that unit. |
|
Honestly, given the API's newly added ability to control vehicles, I don't see attempting to support the Gen3 as remotely necessary. The API should allow us to pace charging to policy, and what the EVSE is offering merely becomes a cap for safety. The next stage of TWCManager should be running as a Docker container with no physical connection to the EVSE, regardless of what it is. |
|
@ngardiner it seems RS485 is starting to appear in firmwares : https://wallmonitor.app/app/firmware/23.8.2 |
|
Tesla now supports load balancing using an external power meter that communicates over RS-485. It seems like a matter of time before someone reverse engineers the protocol. https://www.tesla.com/support/charging/wall-connector/power-management https://www.friism.com/diy-tesla-wall-connector-with-load-management/ |
That's handy, thanks for that. I am assuming they aren't offering Gen2 TWCs as one of the meter types that they support? Bit strange if not given it would be pretty easy for them to support it, but perhaps due to the different power sharing topologies for Gen2 and Gen3. |
|
I doubt the Gen2 and Gen3 will ever be able to communicate with each other. If Tesla had envisioned that it would have happened already IMHO. The FAQ points to a single Tesla-approved power meter for the Gen3: https://www.amazon.com/dp/B0CP8F2H24 |
|
Wouldn't the path of least resistance be the official Tesla Bluetooth API that works for both Gen2 and Gen3 chargers? |
Not really, we don't have any bluetooth infrastructure as part of the platform today. We'd need to implement scanning, peering, and then work out how it communicates over BT protocol-wise, and it would be a one-to-many communications setup rather than the current shared bus over which we can communicate with all stations. Even a completely different rs485 protocol is probably easier since we already have the interface to the serial bus, the queueing and it would still allow us to send all comms out onto the same 2 wire bus, although that is questionable as I know nothing about the power meter protocol used for the Gen3 today, but it's somewhat implicit in the rs485 bus being used that it's probably a similar approach to the Gen2 protocol. |
|
This is so f…. frustrating! I did research BEFORE buying my wall charger, found RJ485 port and esphome solution was all excited and got wall charger today. I don’t want cloud, I don’t even want WiFi. The RJ485 port (which shows even up in the manual of the Gen3 that I skimmed) was the only reason for getting a Wall Charger. Now I need to realize that this works only for the old one but not Gen3? WTF! |
|
I feel your pain and can only agree unfortunately. Tesla has the worst judgement in not providing for their customers in the charging domain. Vehicle charging is easily the largest consumer in the household. Integrating charging into home automation is essential. Yet we have this impossible API that is beyond mere mortals to understand or implement. Very frustrating! |
|
Does anyone here know who reserve engineered the TWC Gen1 and Gen2 RS-485 protocol? Would (s)he be willing to do this again for Gen3? |
|
There's a person at the following thread called @WinterDragoness - If you can spare the time, it's a fascinating read over 33 pages, documenting how the protocol was reverse-engineered. Otherwise, the original TWCManager (by Chris Dragon) is located here - |
|
I believe (it is mentioned in that thread) that cdragon's efforts reverse engineering the TWC protocol stopped when they took up employment that was in some way related to the subject matter. It is important to note that in the process of reverse engineering the protocol, at least 1 (maybe 2?) TWCs were destroyed due to random calls corrupting the firmware. It's not for the feint of heart. |
|
I am not the person listed in this email thread. Sorry for the confusion
and please remove me from this thread.
…On Fri, Apr 26, 2024 at 6:24 AM Nathan Gardiner ***@***.***> wrote:
I believe (it is mentioned in that thread) that cdragon's efforts reverse
engineering the TWC protocol stopped when they took up employment that was
in some way related to the subject matter.
It is important to note that in the process of reverse engineering the
protocol, at least 1 (maybe 2?) TWCs were destroyed due to random calls
corrupting the firmware. It's not for the feint of heart.
—
Reply to this email directly, view it on GitHub
<#292 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AO3YKRLM47DBBAIGIPIJHETY7JIQRAVCNFSM45WELWW2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBXHEZTSMJVGM3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@cdragon sorry I think you were linked by mistake, cdragon is referring to a username in a webforen. Ok, I really hate the Gen3 already and don't even want to install. I don't want Wifi and all that crap. |
|
Actually something is fishy here. According to the teardown in https://teslamotorsclub.com/tmc/threads/tesla-wall-connector-load-sharing-protocol.72830/, Gen 3 doesn’t even have the ICs for RS485 populated. However, as @RichieB2B found above, there is a device which uses the RS485 Port: https://www.amazon.com/dp/B0CP8F2H24 Are there even multiple hardware revisions of the Gen 3? Or is the information wrong? |
|
@segdy I think you posted the wrong TMC link. I found the info in this post https://teslamotorsclub.com/tmc/posts/5449371/ that is part of this thread https://teslamotorsclub.com/tmc/threads/gen3-hpwc-disassembly-with-overheating-issues-explained.223104/ You're right though: that doesn't make sense. I've asked them about it here. Let's see what they answer. Update: they agree that their assessment about the "ICs for RS485" not being populated is probably wrong. |
When I check the Status of the twcmanager with "systemctl status twcmanager.service" looks the output like this:
● twcmanager.service - Tesla Wall Charger Manager
Loaded: loaded (/etc/systemd/system/twcmanager.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-05-28 10:55:33 CEST; 3min 20s ago
Main PID: 628 (python3)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/twcmanager.service
└─628 /usr/bin/python3 /home/pi/TWCManager/TWCManager.py
Mai 28 10:55:33 piLadestation2 systemd[1]: Started Tesla Wall Charger Manager.
Mai 28 10:55:40 piLadestation2 python3[628]: 10:55:40 TWCManager 40 ImportError: No module named 'sentry_sdk', when importing Logging.SentryLogging
Mai 28 10:55:41 piLadestation2 python3[628]: 10:55:41 HTTPContro 20 Serving at port: 8080
Mai 28 10:55:41 piLadestation2 python3[628]: 10:55:41 TWCManager 20 TWC Manager starting as fake Master with id 7777 and sign 77
Starting the fake Master ID, this is where the script gets stuck, what am I doing wrong or what should I pay attention to?
Thanks in advance for your help!
The text was updated successfully, but these errors were encountered: