Support for bl0940 energy monitoring - BW-SHP10 - and Support for 1.5 stop bits in serial communication

[MadDoct]

Have you looked for this feature in other issues and in the docs?
yes Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.

Describe the solution you'd like
A clear and concise description of what you want to happen. Provide suport for bl0940 energy monitoring chip as used by bw-shp10 Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here. It uses UART for communication connected to tx and rx, but also has CF connected to gpio14 it seems to use baudrate 4800 8N and 1.5(?!) stop bits - this may be the problem... I've tried to comunicate with it using serialsend, but can't... Maybe due to the stopbits - tried 8N1 and 8N2 datasheet - http://www.belling.com.cn/media/file_object/bel_product/BL0940/datasheet/BL0940_V1.1_en.pdf

(Please, remember to close the issue when the problem has been addressed)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[arendst]

Still waiting for my banggood ordered device...

[kubiq]

I have the device, but don't even know how to take it apart

[MadDoct]

I took it apart... That's why I have the above information... It is glued together and then soldered...

[arendst]

Got it. Now find the time.

[arendst]

Been playing around with all kinds of serial configs but all I receive is nothing. I'm even wondering if the Tx/Rx from the BL0940 is really connected to Rx/Tx to the ESP8266.

Before I try to open mine @MadDoct can you provide pictures of your opened up device so I/we can trace any additional signals going to/from both chips.

Regarding the 1.5 parity I think using 8N1 with a delay of 104uSec in between bytes send should provide the same functionality. Recieving shouldn't be an issue at 8N1 as the Uart would just handle it anyway having a slight delay between the bytes received.

[arendst]

Just learned there are two versions; with or without metering. I wonder if mine has metering at all....

[arendst]

And re-ordered the metering one.

[MadDoct]

well, thats a pitty... mine is the metering one about the connections, I checked with a multimeter and they are as described in the OP. If you want, I can try modified firmwares or whatever you want @arendst ...

[arendst]

You might want to try the attached file. It is a debug version with alpha code but it should start displaying serial data when you enable Weblog 4.

xnrg_14_bl0940.zip

In my case it displays ziltge, nil, nothing, nada, niets....

[napcode]

You might want to try the attached file. It is a debug version with alpha code but it should start

Tried it but looks like some bits are missing: tasmota/xnrg_14_bl0940.ino:196:31: error: 'ValidTemplate' was not declared in this scope if (ValidTemplate("BW-SHP10") && PinUsed(GPIO_BL0940_RX) && PinUsed(GPIO_BL0940_TX)) {

[arendst]

Add this anywhere:

bool ValidTemplate(const char *search) {
  char template_name[strlen(SettingsText(SET_TEMPLATE_NAME)) +1];
  char search_name[strlen(search) +1];

  LowerCase(template_name, SettingsText(SET_TEMPLATE_NAME));
  LowerCase(search_name, search);

  return (strstr(template_name, search_name) != nullptr);
}

[arendst]

or use latest commit of development.

[napcode]

Added some logs for driver init. Using GPIO01 and GPIO03 as RX/TX I do get those logs. Hence, the template matching seems to work but after that, I don't see life signs from the serial interface. If my order went correct, I should have the metered version. I'll probably play around with the code later tonight.

[Lefuneste83]

I am using 2 SHP10 metering versions. I flashed them with Tuya Convert as I did not want to disassemble them. I used the provided template for the non-metering version which works great except that there is no monitoring.

{"NAME":"BW-SHP10","GPIO":[0,0,0,0,157,21,0,0,0,17,0,0,0],"FLAG":0,"BASE":18}

So I am highly interested in your efforts to communicate with the power metering part. Let me know if I can provide some help.

[corporalp]

Same config as @Lefuneste83 here, I did use folowing template.

{"NAME":"BW-SHP10_3","GPIO":[0,107,0,108,157,21,0,0,0,17,134,0,0],"FLAG":0,"BASE":45}

It shows Power, Today, yesterday, total. Missing voltage & current.

firmware 8.3.1

[arendst]

Research....

[MadDoct]

Wow Theo! That was a little bit "overkill" :)

[arendst]

I seem to have broken it when I tried to remove the top. So I went a bit further...

Now I want to make sure the serial connection between the BL0940 and the ESP8266 is as you suggested.

[MadDoct]

Believe me, it is... I tested it with a multimeter in continuity mode...

[arendst]

You seem to be right.

I still can't monitor any data from the BL0940. I connected wires to Rx and Tx and while powering the device from 5V there is nothing received even when swapping the wires.

There must something more to it to let the BL0940 talk to the ESP8266...

[MadDoct]

Are you sure it has nothing to do with the 1.5 stop bits?

[arendst]

It might but I tried faking it and nothing comes through.

I tried a terminal tool too supporting stopbit 1.5 but it fails on my windows PC UART not supporting 1.5 stopbits...

[napcode]

I didn't manage to get anything either (didn't open the device yet though). Maybe the BL0940 is configured to use SPI insted of UART? According to the manual, pin 10 is used to configure that. Is Pin 10 connected to VDD?

[arendst]

Thx for the info but this device uses the 10-pin BL0940 which doesn't have SPI.

So serial it is.

[CervDotBe]

Just asking, is there any update on this?

[arendst]

Yes.

I received my second SHP-10 yesterday and while still running the default tuya code I'm able to monitor the BL0940 chip. I still need to find the correct serial config as I'm currently using a rewritten software serial interface able to talk 1.5 stopbit.

While monitoring the tuya code I noticed I was wrong with the register request codes.

Using the current code you might be able to receive someting by changing the line Bl0940Serial->write(0x58); into Bl0940Serial->write(0x50);

I'm almost there...

[s-hadinger]

Just out of curiosity, why do we need support for 1.5 stop bits? Just set to 2 stop bits so data transmitted will have at least 2 bits. As far as I recall, the receiver doesn't care about number of stop bits as pong as there is 1.

[arendst]

You beat me to it. I was struggling to get the 1.5 stopbit functional and I did receive data but most of it were zeros. Last night I had the eureka moment that the zeros were caused by a voltage difference caused by 5V/3V6 level change; I powered my opto couplers with 5V while the serial data was being provided on a 3V6 level.

Add 2 diodes solved my voltage problem and using two serial terminals on 4800-8N1 they now provide steady readings so yes, we do not need 1.5 stopbits.

The main issue is that the BL0940 documentation is wrong; to read registers I need 0x50 instead of 0x58.

[arendst]

BTW the optocouplers are needed. I had a 230V shock already this morning.

[arendst]

Progress:

[MadDoct]

very cool @arendst ! Can I try it? Do you have test firmware?

[arendst]

Basic support for BL0940 as used in BW-SHP10 is in current development.

Energy values are not being updated yet.

Use the following template to add energy measurement:

{"NAME":"BW-SHP10","GPIO":[0,148,0,207,158,21,0,0,0,17,0,0,0],"FLAG":0,"BASE":18}

[napcode]

Awesome! I flashed 3 SHP10 with the latest development commit and so far it is working nicely.

[arendst]

Thx for reporting back.

Closing as it has been implemented.

[linkvt]

Hi guys, quick question, does this device still need power monitoring calibration? The documentation of BL0940 says it is calibration free but I'm not deeply into this.

The supported devices page of e.g. Blitzwolf SHP10-P still includes the template for power monitoring calibration for this device but AFAIK it would not be needed, right?

[arendst]

It won't hurt to calibrate I think. Simply use commands Voltageset, Currentset and Powerset. Perhaps just to verify no calibration was needed ;-)

[yoyolb]

Hi guys. Thank you for your work. I have two metered SHP10: they work fine with latest development build except Energy Today/Yesterday/Total. The value is about 10 times too high.

[arendst]

Energy Today is calculated using the active_power value returned by the BL0950. Active_power is represented by a value related to power used within one hour.

So a 60W incandescant bulb uses 60W per hour. It should have been called 60Wh. This translates to 0.060kWh.

To achieve this value every second the active_power is divided by 3600 and fed to the Energy Today counter.

If I use the 60W bulb it indeed increments Energy Today every minute with 0.001kWh resulting in the final 0.060kWh after one hour.

What is your kind of load? Perhaps you can report the internal BL0940 registers by enabling logging level 4 (weblog 4) for a minute to see how the, currently unused, CF pulses increment.

[Lefuneste83]

Hi guys. Just a quick notice from my experience following your developments. I have tried the suggested template {"NAME":"BW-SHP10","GPIO":[0,148,0,207,158,21,0,0,0,17,0,0,0],"FLAG":0,"BASE":18} against the latest dev version I could get from the repo yesterday (8.3.1.2) that I compiled and uploaded to the device. I previously had a 8.3.1 also compiled and the other recommended template {"NAME":"BW-SHP10","GPIO":[0,107,0,108,157,21,0,0,0,17,134,0,0],"FLAG":0,"BASE":45}.

In 8.3.1 I get instant power working once calibrated. In 8.3.1.2 I get a fully functional device with voltage and all the data showing and updating nicely once calibrated. Both had SetOption19 1 and SetOption65 1 (tried also with 0 for the second one).

But I have a weird behavior with the latest dev version and template. Please take it with a grain of salt as I am still investigating. After a random period, the device turns itself off. I have seen this happening several times since yesterday. This seems to occur at random intervals with nothing going on elsewhere in the MQTT queue. This did not seem to occur in 8.3.1. I am rolling back to 8.3.1 now with the previous version of the template to see if this is related to the upgrade. I have looked into my MQTT queue to see if something external would trigger the OFF command but so far, it seems that the device turns itself off without any command behind sent to it. I have no retain status anywhere and the device is not integrated yet to any automation, just logged into the broker (with TLS active should I add). Timers are obviously not active.

I see that the latest template requires at least 8.3.1.3+ version but I could not find it as the dev branch seems only at 8.3.1.2. (as of yesterday) I have upped the log levels to try to catch the event that triggers the change of state but I am puzzled as to what causes this event.

Any clues about this ? Maybe the dev branch I used does not have the commits yet ?

[yoyolb]

Hi guys.

@arendst : my load is a motor (water pump). Current (~6A), voltage (~235V) and power factor (~0.91) are reported as expected. Power values look OK also. I made some tests with a SONOFF POW R2 which gives the same current/voltage/power factor values and correct Energy Today/Yesterday/Total with the same load. So I think there is a problem in the way Energy is computed with BL0940 chip.

I will try to get and report internal registers as requested.

@Lefuneste83: I have experienced same issue as you with my device that unexpectedly turned off from time to time.

[arendst]

The power off may be overtemp like I've seen:

15:26:14 MQT: tele/shp10/STATE = {"Time":"2020-06-12T15:26:14","Uptime":"0T03:52:15","UptimeSec":13935,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"ON","Wifi":{"AP":2,"SSId":"indebuurt_IoT","BSSId":"18:E8:29:CA:17:C1","Channel":11,"RSSI":100,"Signal":-46,"LinkCount":1,"Downtime":"0T00:00:07"}}
15:26:14 MQT: tele/shp10/SENSOR = {"Time":"2020-06-12T15:26:14","ENERGY":{"TotalStartTime":"2020-06-07T14:29:21","Total":2.383,"Yesterday":0.000,"Today":2.343,"Period":161.87,"Power":0.00,"ApparentPower":0.00,"ReactivePower":0.00,"Factor":0.00,"Voltage":238.8,"Current":0.000,"BL0940":{"Temperature":44.0}},"TempUnit":"C"}
15:30:43 SRC: Overtemp
15:30:43 MQT: stat/shp10/RESULT = {"POWER":"OFF"}
15:30:43 MQT: stat/shp10/POWER = OFF
15:30:43 CFG: Saved to flash at F8, Count 182, Bytes 4096
15:31:14 MQT: tele/shp10/STATE = {"Time":"2020-06-12T15:31:14","Uptime":"0T03:57:15","UptimeSec":14235,"Heap":28,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":2,"SSId":"indebuurt_IoT","BSSId":"18:E8:29:CA:17:C1","Channel":11,"RSSI":100,"Signal":-46,"LinkCount":1,"Downtime":"0T00:00:07"}}
15:31:14 MQT: tele/shp10/SENSOR = {"Time":"2020-06-12T15:31:14","ENERGY":{"TotalStartTime":"2020-06-07T14:29:21","Total":2.494,"Yesterday":0.000,"Today":2.454,"Period":110.67,"Power":0.00,"ApparentPower":0.00,"ReactivePower":0.00,"Factor":0.00,"Voltage":238.5,"Current":0.000,"BL0940":{"Temperature":43.8}},"TempUnit":"C"}

Will investigate as it should overtemp at 90 C

[arendst]

To monitor if invalid overtemp is causing the power off enable logging level 3 and watch the above shown message when your power goes off.

The latest fix will also report the overtemp temperature.

[Lefuneste83]

Amazing ! Thanks for the info Theo. I'll have a look at this. FYI, I haven't had a POWER OFF since rolling back to 8.3.1 with previous template so it looks like a side effect so far. I'll push the new version again with logs up to your suggested level.

[arendst]

Hold on. Just noticed the BL0940 receives valid data but the temp is wau too high causing the overtemp to trigger:

17:22:07 BL9: U 151808, I 87296, P 5585408, T 52149
17:22:07 NRG: GlobTemp 9837.2
17:22:07 SRC: Overtemp
17:22:07 MQT: stat/shp10/RESULT = {"POWER":"OFF"}
17:22:07 MQT: stat/shp10/POWER = OFF
17:22:07 CFG: Saved to flash at FB, Count 217, Bytes 4096

Currently working on yet another fix :-)

[Lefuneste83]

Indeed... A tad high... I've installed the new version and increased the log anyhow. Now I am waiting for the event...

[arendst]

In 8.3.1 there was no energy monitoring for BL0940 hence no overtemp control.

[Lefuneste83]

I see... This explains the different behavior...

[Lefuneste83]

Compiled and applied the latest commit, no power off so far (about 4 hours straight vs less than 1 hour before)... Seems fine, will leave it overnight and see what happens.

[arendst]

@yoyolb the latest commit contains another way of calculating energy usage.

Pls try and report back if the Energy Today values are more in line with what you expect.