Driver for Tuya Energy Meter - Hiking DDS238-2 WIFI

[chaveiro]

Currently there is only native support for the ModBus version.
This request is for the Wifi version that has a TuyaMcu for energy measuring (with total kw/h accumulation build in) and a TYWE3S / ESP8266 with 1Mb Flash inside the same device.

Some previous work on manual config available here https://github.com/krikk/Hiking-DDS238-2-WIFI-Din-Rail-Energy-Meter-flashing-Tasmota
Also compatible with eMylo EAI-90 if you replace the WB3S Module by an ESP-12

Current TuyaMCU driver already supports this device with bellow config:

{"NAME":"Hiking DDS238-2 WIFI","GPIO":[0,2272,0,2304,0,0,0,0,0,0,320,0,32,0],"FLAG":0,"BASE":54}


Backlog TuyaMCU 33,20; TuyaMCU 32,18; TuyaMCU 31,19;  TuyaMCU 37,101;
Backlog SetOption72 1; VoltRes 1; WattRes 1;

Rule1 
  ON System#Init DO backlog tuyasend1 1,1; RuleTimer1 5; ENDON 
  ON Rules#Timer=1 DO backlog TuyaSend8; RuleTimer1 5 ENDON

Backlog Rule1 1; 

Backlog EnergyReset1 0; EnergyReset2 0; EnergyReset3 0

restart 1

My request is to make a native supported Module for this device with all the configurations set automatically.
Add a new driver that uses TuyaMCU driver as the helper to pool the Tuya MCU every 2-3 second, and gather the data on the energy driver so the tele-Energy works seamlessly without custom configurations.

I can help testing or even create some code, just have difficulty starting up.

Sample end result:
11:13:05.937 MQT: stat/Tasmota/STATUS8 = {"StatusSNS":{"Time":"2021-04-29T11:13:05","ENERGY":{"TotalStartTime":"2021-04-28T00:00:00","Total":5.127,"Yesterday":2.850,"Today":1.907,"Power":1771.5,"ApparentPower":1857.3,"ReactivePower":558.2,"Factor":0.95,"Voltage":234.1,"Current":7.934}}}

[hallard]

@chaveiro very interesting an promising. Just one question because something is not clear for me. When flashed with tasmota, this means that device (not the Wifi part but CPU part of DDS238) is just sending data over serial, correct?
If so do you know what is the data format so we can decode them using other kind of CPU or application? Assuming we're on 3.3V TTL.
Thanks

[chaveiro]

The data format from the TuyaMCU is known and working, see on tasmota code or here for more details: https://www.creationfactory.co/2019/12/reverse-engineering-zmai-90-din-rail.html

[barbudor]

@chaveiro
As far as I understand you have a working solution using module 54 (TuyaMCU) and rules.
The code to parse the energy message from the MCU is already there and working.

So it looks like you have the solution and should be documented in the template repository.

Templates, rules, scripting etc... are here for that purpose : customize Tasmota framework to a specific device without adding code. Hard coding a specific device in the code is restricted to devices where this cannot be done differently which is obviously not the case here.

Please document your findinds into Tasmota template repository : https://templates.blakadder.com/new.html

@hallard the decoding of TuyaCMU Energy message is performed in xdrv_16_tuyamcu.ino. Search for ENERGY.

[chaveiro]

There are a couple problems with the templating solution for this scenario:

• needs to set a lot of aditional options to the tuya driver and the energy driver that are not part of the template and not easy known to the user without a recipe that can change as tasmota code evolves. (As happened in the past)

• Tuya MCU is 'overloaded' by the 'default' tuya driver as it does a regular PING and we are also pooling for energy data every 5s via the custom timer. Shouldn't the driver knows it's an energy device and stop the PING when the pooling is running?

• Spam mqtt with aditional messages for each timer etc that also impacts additional scripting if you need to act on energy data. Eg.: I'v added a buzzer with additional rules (my customization) and the beep patterns gets random as the esp is doing lot of additional 'stuff' that could be simplified with a specific module for this device.

Added the templating as requested on tasmota template repository. But that is not enough to configure the device.