TWC signals an error

[pavelkonir]

Even if a charger is added to the controller and a heartbeat is sent to it, the TWC suggests an error via the diodes (the upper green lights up and the red one flashes 4 times). So it claims that there is no master.

[jnicolson]

Firstly thanks for your interest!

What are you using in the way of electronics to connect to the TWC? A custom board (like the one in my other repo) or a breadboarded type solution?

If you share what the hardware is to start with (which ESP32 and RS485 transceiver and how they're connected) it'd be good.

Also, if you send a 1 to the MQTT topic twcController/debugEnabled it will start to put any data received onto the MQTT topic twcController/debug/packetReceive and also onto the serial port. Do you see anything on that topic or serial? If you don't it would suggest the messages aren't making it sucessfully to the ESP32. It doesn't need to have sucessfully negotiated a primary/secondary relationship to write those packets - it'll write any full packets (something bookended with C0 hex).

[pavelkonir]

I draw from your project, I build it on the M5Stack + RS485 board. (https://m5stack.com/products/lan-module-w5500-with-poe)
I don't have it attached to MQTT and when I turn on debug, in code below.
TWC is switched on as slave (switch in position F). I thought ESP32 was simulating a master. I write the program in Visual studio code with the platform installed.

Communication from my project:
Starting up Tesla Controller task as primary... Done! Sent packet: c0fce132ab77400600000000000000007bc0ff Sent packet: c0fce132ab7740060000000000000000bac0ff Sent packet: c0fce132ab7740060000000000000000bac0ff Sent packet: c0fce132ab7740060000000000000000bac0ff Recieved Packet: fde28725ae0c800000000000000000c8 New charger seen - adding to controller. ID: 2587, Sign: ae, Max Allowable Current: 3200 Sent packet: c0fce132ab7740060000000000000000bac0ff Sent packet: c0fbe232ab77400600000000000000007cc0ff Sent packet: c0fbe232ab77400600000000000000007cc0ff Sent packet: c0fbe232ab77400600000000000000007cc0ff Sent packet: c0fbe232ab77400600000000000000007cc0ff Sent packet: c0fbe232ab77400600000000000000007cc0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbef32ab872500000000000078c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbf132ab87250000000000007ac0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbed32ab872500000000000076c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbeb32ab872500000000000074c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbec32ab872500000000000075c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbef32ab872500000000000078c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbf132ab87250000000000007ac0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbed32ab872500000000000076c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbeb32ab872500000000000074c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbec32ab872500000000000075c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff

Communication from your project:
Booting... Starting Tesla Controller... Done! Setting maximum current to 16 Setting minimum current to 5 Setting stop/start delay to 300 Starting up Tesla Controller task as primary... Done! Sent packet: c0fce132ab77800c0000000000000000c1c0ff Sent packet: c0fce132ab77800c000000000000000000c0ff Sent packet: c0fce132ab77800c000000000000000000c0ff Sent packet: c0fce132ab77800c000000000000000000c0ff Sent packet: c0fce132ab77800c000000000000000000c0ff Recieved Packet: fde28725ae0c800000000000000000c8 New charger seen - adding to controller. ID: 2587, Sign: ae, Max Allowable Current: 3200 Sent packet: c0fbe232ab77800c0000000000000000c2c0ff Sent packet: c0fbe232ab77800c0000000000000000c2c0ff Sent packet: c0fbe232ab77800c0000000000000000c2c0ff Sent packet: c0fbe232ab77800c0000000000000000c2c0ff Sent packet: c0fbe232ab77800c0000000000000000c2c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbef32ab872500000000000078c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbf132ab87250000000000007ac0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbed32ab872500000000000076c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbeb32ab872500000000000074c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbec32ab872500000000000075c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff Recieved Packet: fde2872f3c0000c8 Error processing packet - checksum verify failed. Full packet: fde2872f3c0000c8 Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbef32ab872500000000000078c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbf132ab87250000000000007ac0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbed32ab872500000000000076c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbeb32ab872500000000000074c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbec32ab872500000000000075c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbef32ab872500000000000078c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbf132ab87250000000000007ac0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbed32ab872500000000000076c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbeb32ab872500000000000074c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbec32ab872500000000000075c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbef32ab872500000000000078c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbf132ab87250000000000007ac0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbed32ab872500000000000076c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbeb32ab872500000000000074c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbec32ab872500000000000075c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Recieved Packet: fde28725ae0c800000000000000000c8 Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbef32ab872500000000000078c0ff Recieved Packet: fde28725ae0c800000000000000000c8 Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbf132ab87250000000000007ac0ff

[jnicolson]

Thanks for the serial output. It is correctly seeing the secondary device, but the heartbeat being sent back is "empty", so the secondary doesn't know what to do.

If you're not connecting it to MQTT, you'll have to somehow call SetCurrent with the current you want the primary to advertise. To test if it's working, you could set this in twc-controller.ino by calling controller.SetCurrent(16); if you wanted to advertise 16 Amps available.

If you're not going to use MQTT, whichever way you choose to adjust the current will just need to call SetCurrent on the controller instance each time it wants to change the available current. I had intentions of exposing this via a web interface, but other tasks have come up.

Hope this helps!

[jnicolson]

Also - a question for you, it looks like you expected it to work differently from what it does - are you able to describe what you thought it would do? I'm interested in making it as simple as painless as possible for people.

[pavelkonir]

I launched your version, including the connection to MQTT. I send commands to twcController / availableCurrent there, in the serial log it can be seen that the command will be accepted. But TWC still flashes that it has no master. The log is below. So it probably won't be a problem that I removed mqtt, which uses a library that is not compatible with the platform. I expected your application to set a default charging value after startup, such as 16A, and that it would work at least on this side. I don't want to use wifi, so I added an implementation for ethernet and I want to use the display on the M stack for charging information and buttons to turn off charging and set the current manually. I want to implement MQTT there via another library. I would also like to block charging based on the VIN of the connected car.

Sent packet: c0fbf132ab87250000000000007ac0ff Recieved Packet: fde28725a10c800000000000000000bb Received current change message, new current 15 Sent packet: c0fbe032ab87250905dc00000000000053c0ff Sent packet: c0fbed32ab872500000000000076c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbeb32ab872500000000000074c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbec32ab872500000000000075c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbee32ab872500000000000077c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Recieved Packet: fde28725a10c800000000000000000bb Sent packet: c0fbef32ab872500000000000078c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbf132ab87250000000000007ac0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbed32ab872500000000000076c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbeb32ab872500000000000074c0ff Sent packet: c0fbe032ab872500000000000000000069c0ff Sent packet: c0fbec32ab872500000000000075c0ff Recieved Packet: fde28725a10c800000000000000000bb Recieved Packet: fde28725a10c800000000000000000bb

[pavelkonir]

WHen I try python TWCManager, then packets are diferent.

Python version:
16:38:06 TWCManager 1 TWC Manager starting as fake Master with id 7777 and sign 77 16:38:06 TWCMaster 8 Send master linkready1 16:38:06 IfaceRS485 9 Tx@: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0 16:38:06 TWCMaster 8 Send master linkready1 16:38:06 IfaceRS485 9 Tx@: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0 16:38:06 TWCMaster 8 Send master linkready1 16:38:06 IfaceRS485 9 Tx@: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0 16:38:07 TWCMaster 8 Send master linkready1 16:38:07 IfaceRS485 9 Tx@: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0 16:38:07 TWCMaster 8 Send master linkready1 16:38:07 IfaceRS485 9 Tx@: C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0 16:38:07 TWCMaster 8 Send master linkready2 16:38:07 IfaceRS485 9 Tx@: C0 FB E2 77 77 77 00 00 00 00 00 00 00 00 47 C0 16:38:07 TWCManager 9 Rx@: () FD E2 87 25 73 0C 80 00 00 00 00 00 00 00 00 8D 16:38:07 TWCManager 1 32.00 amp slave TWC 8725 is ready to link. Sign: 73 16:38:07 TWCManager 1 Set slave TWC 8725 protocolVersion to 2, minAmpsTWCSupports to 6. 16:38:07 IfaceRS485 9 Tx@: C0 FB E0 77 77 87 25 00 00 00 00 00 00 00 00 00 7A C0 16:38:07 TWCMaster 8 Send master linkready2 16:38:07 IfaceRS485 9 Tx@: C0 FB E2 77 77 77 00 00 00 00 00 00 00 00 47 C0 16:38:07 TWCMaster 8 Send master linkready2 16:38:07 IfaceRS485 9 Tx@: C0 FB E2 77 77 77 00 00 00 00 00 00 00 00 47 C0 16:38:07 TWCManager 9 Rx@: (FC) FD E0 87 25 77 77 00 02 58 00 00 00 00 00 00 D4

Your version:
Sent packet: c0fce1777777800c000000000000000011c0ff Sent packet: c0fce1777777800c000000000000000011c0ff Sent packet: c0fce1777777800c000000000000000011c0ff Sent packet: c0fbe2777777800c0000000000000000d3c0ff Sent packet: c0fbe2777777800c0000000000000000d3c0ff Sent packet: c0fbe2777777800c0000000000000000d3c0ff Sent packet: c0fbe2777777800c0000000000000000d3c0ff Sent packet: c0fbe2777777800c0000000000000000d3c0ff Recieved Packet: fde287258f0c800000000000000000a9 New charger seen - adding to controller. ID: 2587, Sign: 8f, Max Allowable Current: 3200 Sent packet: c0fbe0777787250000000000000000007ac0ff Sent packet: c0fbee7777872500000000000088c0ff Sent packet: c0fbe0777787250000000000000000007ac0ff Sent packet: c0fbef7777872500000000000089c0ff
C0 FC E1 77 77 77 00 00 00 00 00 00 00 00 46 C0 vs c0fce1777777800c000000000000000011c0ff

Pzthon vesrion get slave ID 8725 and your version has ID 2587, why is switched?

[pavelkonir]

Maybe the problem is that the bytes are swapped (bigendian). In the C library from which you obviously started, bswap methods are used. I didn't find them in your code. Does it really work for you?

[jnicolson]

Sorry to hear it's not working, it's definitely working for me. Byte swapping is definitely happening, it's just named htons and htonl (and their inverse, ntohs and ntohl (standing for Host to Network Short, Host to Network Long and the opposite). I can't remember exactly why I decided to use this naming rather than bswap, but it came straight from the Arduino ethernet library (https://github.com/arduino-libraries/Ethernet/blob/75a3c37b5e513305b82e926ca6a4f8190f536c9d/src/utility/w5100.h#L459-L466)

The reason you're seeing it as 2587 is that i didn't byte swap it before printing - if you look at the packets between the Python version and mine you'll see it's sending it the same way (spaces added for clarity):

16:38:07 IfaceRS485 9 Tx@: C0 FB E0 77 77 87 25 00 00 00 00 00 00 00 00 00 7A C0
vs
______________Sent packet: C0 FB E0 77 77 87 25 00 00 00 00 00 00 00 00 00 7A C0 ff

At this point i'm not 100% sure why it's not working for you. It's actually like the TWC isn't receiving the messages sent from the controller. This is probably something i'll need to put a check in for - if the controller has seen a TWC but it's not responding to heartbeats then it should be dropped, but that won't help in your case, it would just make it more clear what's happening.

Are you positive your RS485 transceiver is sending data and making it to the other end? Do you have any other RS485 transceivers which you could test with (i.e. looks like you've got one to run the Python twcmanager, can you make sure you're receiving data by connecting the two together)?

[pavelkonir]

The RS485 interface is functional. I tried 2 RS485 modules on 2 ESP32 and the communication between them works. For the python version I have a USB / RS485 interface. I just reconnected the wires from the TWC to another adapter. I tested your application on 2 M5 stack and M5 ATOM devices. If the communication did not work, it would not get to the controller from the right that there is a slave on the line. Or does the slave send messages about the person himself? Would sending from ESP to TWC not work for me for some reason?

[jnicolson]

A TWC set to secondary mode will send presence packets (FD E2) even if it doesn't see anything on the other end, so the controller will "see" the TWC even if it can't really communicate with it.

I tried to find the schematic for the RS485 board included with that Ethernet module but there didn't seem to be one. I found schematics for other RS485 boards produced by M5 (https://docs.m5stack.com/#/en/atom/atomic485?id=schematic) and I actually am unsure how they are operating as senders - they don't show transmit connected to the DI pin (it's tied to ground) and they are driving the RE/DE pins from TX. I've never seen this before - it's definitely not what I would expect to see for a standard RS485 setup (driving RE/DE from a timer sure, but not directly from TX).

I don't know enough about RS485 at a hardware level to know what impact this might have on a TWC unfortunately.. If you're really looking to use an ESP32 i could only suggest picking up a cheap RS485 module which breaks out the DE/RE line and seeing if driving it the normal way works any better..

[pavelkonir]

Yes, this is bad circuit. The module is in receiver mode only. Sorry for my mistake, thank you for your cooperation. I'll make a converter that will work there.

[pavelkonir]

Hi, I made an RS485 converter according to your schematic. I connected it to TWC and still have the same problem.