Vevor level 1/2 EV Charger #21385
Replies: 3 comments
-
You did it correctly. Issues are for fully qualified bugs with all information for reproducing to allow debugging by the dev team. Not getting what you expect from a brand new device, especially one that has been brain-converted is not an issue but a call for help. Back to your problem, you are not clear on what dpId/fnId mapping you tried and haven't provided any logs. A properly mapped dpId/fnId should be decoded by Tasmota and should be presented in hte SENSOR message On dpId 6, if it is a combined voltage/current/power, the proper fnId is 36 and should be decoded by Tasmota (if properly configured) - obviously doc need to be updated for those missing fnId that can be found in the code: Tasmota/tasmota/include/tasmota.h Lines 551 to 570 in 2f3663b On dpId9, if it is power, fnId should 31 and indeed Tasmota is considering it as deciWatt as documented On your 3rd point, TuyaMCU not sending may any udpdate could be that it doesn't consider that it is connected to it's cloud Definitively providing logs at level 3 would be helpfull to understand the situation Alternatively there is a TuyaMCU Bridge mode (using GPIOs "TuyaMCUBr Tx/Rx" which will transfer any Tuya message over MQTT to your backend for processing htere. So you will have to fully handle the protocol on your side instead of letting Tasmota doing it. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the pointer! Setting fnId 31 to dpId 9 does indeed populate the voltage, power and current (I did also need to disable dpId 9 as that appears to still override it with the divided number, but that's fine) so that solves issues 1 and 2. I had actually had a quick look through the code but it's always hard to find something you're not even sure if it's there, or what it might be called. MQTT was already working obviously, got many other Tasmota or alike devices connected to the system already. I was also able to extract the other random info (like the charge state) for Prometheus by turning on the TuyaMCU to MQTT bridge. 
Basically everything works now, just so long as I set up a timer to manually run TuyaSend0, my issue 3 above. Here's a log for what happens after I start up the ESP-02S: |
Beta Was this translation helpful? Give feedback.
-
|
Okay, trying it again (after noticing the above log did mention unrequested updates) they do very occasionally appear from the MCU automatically, but after sitting watching it for a bit, it looks like the MCU is reporting once every ten minutes. Is that to be expected? :) |
Beta Was this translation helpful? Give feedback.
-
Hey all - this may be better filed as a simple Issue, but thought I'd start here.
Basically, though I'm a software engineer I'm fairly new to Tasmota, used it in a few blinds/etc. but this is my first time using it in a non-supported device. Don't feel confident posting a template yet, but I do have some info.
These chargers, available on Amazon for only $100 for the non-LCD screen version, contain a Tuya module, though it's not an ESP. It's a WBR2 (for which there are SDKs floating around, but that's obviously not the target of the Tasmota project), but it's compatible with the ESP-02S so I grabbed a few of those from Aliexpress, slapped Tasmota in one, and installed it. As an aside, the rest of the device seems to be quite nicely designed for the price, no shockingly (haha) bad choices on the PCB that I could see. The real manufacturer of the system/PCB is "Zopoise".
Anyway, after setting the Tuya RX/TX pins to the ones marked RX/TX on the ESP-02S itself (it looked like those were the only parts hooked up on the main PCB other than power) and setting it to 115200bps, I could indeed talk to the MCU. I got some details from this thread: make-all/tuya-local#1757 (mostly useful as I dislike Tuya the company enough that I didn't want to connect it even once just to grab the info myself). The first post seems to be incorrect but does list the various enum states, if you google some of those you can also find other instances. For ref here's a little spreadsheet I made with the mappins to Tasmota I guessed (I included more info in the "comments" but sadly the Github import won't capture those, and also I think some of the units are probably wrong from the thread):
Either way, everything largely works, but I have a couple of questions:
1 and 2 I can obviously solve on my server end, 3 I can fix with a rule triggering every few seconds, but I just wondered if there's anything else I can try? Obviously other devices may also come out with slightly odd readings in power/etc. (I know there's mention of some outlets also using the same binary format for phase_a) so presumably I should file issues for at least those ones?
Thanks! :)
Beta Was this translation helpful? Give feedback.
All reactions