logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter

TurkeyMan 12510 67

TL;DR

  • PZIOT-E01 is a DIN rail pass-through energy meter from AliExpress, with a hole for the measured wire and an internal CT wrapped around it.
  • Inside, two boards connect by ribbon: a CBU and BL0942 meter chip, with the BL0942 linked by SPI instead of RS232.
  • OpenBK7231N_QIO_1.15.152.bin flashed successfully with uartprogram on COM7 using --unprotect and --startaddr 0x0.
  • Traced pinout includes P9 CF1, P14 SCLK_BPS, P16 RX/SDI, P17 TX/SDO, P20 Bluetooth button, and P22 status LED.
  • SPI support is still missing, but a proposed hack would convert the device to UART so the existing BL0942 driver can work.
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #31 20475449
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    @Digga, did you power off your device during OTA?
    If not, then I am not sure what might have happened.
    Maybe we need to disable drivers for OTA time? The device will restart automatically after OTA anyway...

    Did you have any drivers running?

    Take care with that big capacitors - large capacitance can overload USB port at connect time. USB has a limited current capability, if I remember correctly, the base standard is 500mA and large capacitor can take more than that at connect time to charge.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #32 20478343
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Quote:
    @Digga, did you power off your device during OTA?

    No

    Quote:
    Did you have any drivers running?

    I'm not sure. I thought I always restarted the device to do the OTA without any drivers running.

    I think my work flow was not very efficient. I used log outputs in the web app for debugging and used OTA to test new code. After I posted, I found out, that inserting a log inside of disabled interrupt blocks (or maybe also inside of interrupt routines) the system is not usable anymore (dead lock?) and I bricked it that way. I didn't investigated why but probably that was always the cause...

    Quote:
    Take care with that big capacitors - large capacitance can overload USB port at connect time. USB has a limited current capability, if I remember correctly, the base standard is 500mA and large capacitor can take more than that at connect time to charge.

    Good point! I didn't think about that at all. Yes, USB 2.0 has 100mA and USB 3.0 has 500mA. I think if it isn't a very old computer the USB port should only shut down and don't get any damage in case of overcurrent. Also the capacitor is on the 3.3V side and the LDO can only deliver 250mA.

    Added after 6 [minutes]:

    Good news: Finally I got it to work with SPI!!!
    I still have to do some code clean up and have a look, that it still compiles with the T version, before I can do a pull request.

    Would you add a driver bl0942_spi or would you add an option to the bl0942 driver?
  • #33 20478455
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Wow, that's a very good news @Digga ! Well done! Can you tell us here how to do that?

    Regarding the driver... well... to be honest, I am not sure. There is a design flaw with calibration data/functions being repeated in BL0937 and BL0942 drivers and I was planning to fix that soon. I really need to do some kind of small rewrite of those drivers. But during last few days, I've been busy with docs:
    https://github.com/openshwprojects/OpenBK7231T_App/tree/main/docs
    maybe do a separate file for now and I will do reorganization later, or how advanced are you with that SPI? Is it working over SPI now?
    Helpful post? Buy me a coffee.
  • #34 20478523
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Quote:
    Can you tell us here how to do that?

    Well, the beken_os SPI drivers did not work. I think the programmers started with the drivers but didn't finish them. And without haven documentation of the registers I spent a lot of time trying without success. I finally found the armino project. For the N version probably the best would be to port everything to armino or vise versa. But that sound like a lot of work. Thus I ported the armino SPI driver to the current project. I will do pull request, when I cleaned the code a little bit more.

    Quote:
    There is a design flaw with calibration data/functions being repeated in BL0937 and BL0942 drivers and I was planning to fix that soon.

    I haven't looked into the BL0937 driver yet, thus I cant tell if combining them into one file is better or extracting same functionality into a separate file. Maybe you already have plans.

    Quote:
    Is it working over SPI now?

    Yes. I have now the same functionality as the uart driver. Currently it is hacked into uart driver. Thus SPI is working but uart not anymore.

    I want to advance the functionality, but that comes later. For the BL0942 I think now, that putting uart and SPI into one file sounds reasonable. And to select if uart or SPI should be used we still could add an "startDriver bl0942_spi"?
  • #35 20478551
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Yes, that would be good:
    Code: text Expand Select all Copy to clipboard
    
startDriver BL0942SPI

    without underscore, because recently I started to care more about using shorter names to save just a few bytes.... W600 has very limited memory in comparison to BK and we also want to support it in the future if needed, although currently the SPI driver will be of course enabled only on BK.

    Generic SPI driver would be great, I can help with coding and testing, I can also add some more drivers on top of SPI code, I must check what kind of SPI modules I have at hand.

    Regarding power metering merge - CSE, BL0942 and BL0937 seem to have common parts that could be merged together. Some parts are already merged in bl_shared, but we can do better than that
    Helpful post? Buy me a coffee.
  • #36 20480622
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Code: text Expand Select all Copy to clipboard
    startDriver BL0942SPI

    Done.

    Quote:
    Generic SPI driver would be great, I can help with coding and testing, I can also add some more drivers on top of SPI code, I must check what kind of SPI modules I have at hand.

    I agree. I like the interface of the SPI driver I ported and would take that definitions as the generic SPI driver interface. You will see when I finish it and upload/make a pull request.

    Quote:
    Regarding power metering merge - CSE, BL0942 and BL0937 seem to have common parts that could be merged together. Some parts are already merged in bl_shared, but we can do better than that

    Yes, the calibration routines. I leave that for later :)
  • #37 20481150
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    I am really curious to see how your SPI code works. With SPI interface, we could even attach external memory and use it to, for example, store measurements data or host larger pages on LittleFS.
    Helpful post? Buy me a coffee.
  • #38 20481371
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Sounds interesting :)

    I have some questions regarding style guide:

    1. Project OpenBk7231N and probably all other compatible projects/os, which are using the OpenBK7231T_App use C99 (and not C89) standard. Thus declaring variables in a function have not to be at the beginning of the function. For me declaring the variables where I need them makes the code much more readable and shorter.
    Is it desired, that new code still declares the variables in the beginning of functions (C89)?

    2. Is it desired, that static functions also have the prefix like of the component, i.e. "BL0942" for BL0942_TryToGetNextBL0942Packet? (For me that is totally unnecessary and only makes the function names longer.

    3. Does it have a reason, that often the functions are not declared in the header file (or the header file even doesn't exists)? And the function declarations (prototypes) are copied to other files, where they are needed. For me the proper way is to just include the header file with the function declarations.

    4. I' used to keep a 80 char line limit and break longer lines. Is it ok to do it?

    I'm asking, because I would like writing code that is not only working, but also as readable as possible. But people have different taste of code fomating and I would respect the project style guide, even if I don't like it. (It won't reformat everything, just code I add.)
  • #39 20481432
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Digga wrote:

    1. Project OpenBk7231N and probably all other compatible projects/os, which are using the OpenBK7231T_App use C99 (and not C89) standard. Thus declaring variables in a function have not to be at the beginning of the function. For me declaring the variables where I need them makes the code much more readable and shorter.
    Is it desired, that new code still declares the variables in the beginning of functions (C89)?

    I declare variables at the beginning of the functions because it is easier for me to estimate the stack size of the function call and stack size on microcontroller platforms is limited, but it is not necessary. It's preferred. We already have libraries that use newer standard, like LittleFS.

    Digga wrote:

    2. Is it desired, that static functions also have the prefix like of the component, i.e. "BL0942" for BL0942_TryToGetNextBL0942Packet? (For me that is totally unnecessary and only makes the function names longer.

    I think it can be up to you, but at least try to make non-static function names prefixed.

    Digga wrote:

    3. Does it have a reason, that often the functions are not declared in the header file (or the header file even doesn't exists)? And the function declarations (prototypes) are copied to other files, where they are needed. For me the proper way is to just include the header file with the function declarations.

    Functions should be declared in headers, but in some cases have consolidated multiple headers into single one, thus: drv_local.h and drv_public.h . All called functions must be declared first, otherwise you will get warnings during compilation. Also there may be some quick checks/fixes that are not properly placed in header, but we're going to fix them.

    Digga wrote:

    4. I' used to keep a 80 char line limit and break longer lines. Is it ok to do it?

    No problem


    The reason for slightly messy style is that project went through several iterations very quickly. Our iteration history includes:
    1. my initial HTTP version on windows
    2. port to BK7231T SDK (it was BK7231T-only back then)
    3. port to XR809 SDK
    3. proper multiplatform rewrite
    4. addition of Windows port (so it can run on Windows, with Simulator)
    and we will have to reorganize few things soon
    Helpful post? Buy me a coffee.
  • #40 20482308
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Sounds good, thanks for the explanations.

    Added after 2 [hours] 9 [minutes]:

    I have never commit to github anything yet and I'm new to this. Just created an account. Am I correct with the work flow:
    1. Fork repository
    2. Create new branch
    3. Commit to the new branch
    4. Make a pull request for the new branch/commit

    Added after 15 [minutes]:

    I'm watching youtube videos, sorry for bothering with that :D
  • ADVERTISEMENT
  • #41 20484821
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    I see you have resolved the Git issue and made a pull request, thank you!

    I have merged your changes, but there seems to be issue with paths. Can you resolve it, even by adding a logging declaration to your source file or with some other simple kind of work around?
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    We don't have a standarized way of calling OBK functions from within SDK, we usually assume that SDK is not OBK-aware.

    Or should I fix it myself?
    Helpful post? Buy me a coffee.
  • #42 20486339
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Quote:
    I see you have resolved the Git issue and made a pull request, thank you!

    Sure. And I'm not done yet :)

    Quote:
    I have merged your changes, but there seems to be issue with paths. Can you resolve it, even by adding a logging declaration to your source file or with some other simple kind of work around?
    We don't have a standarized way of calling OBK functions from within SDK, we usually assume that SDK is not OBK-aware.

    I would totally assume that. When I added the logging and logging include the SPI didn't work and I tried to debug with that. I didn't realize, that I used the OBK logging in the SDK and also forgot to remove it.
    As it is working now we don't need that logging and you already fixed it. Thanks.

    I wonder, if I do commit to OKB/The App, how often should I send a pull request? After each completed task, even it is very small? With more pull requests the risk of merging conflicts is smaller...
  • #43 20489226
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Well. pull requests can be updated after submitted, so the real question should be how often do we want to merge... I think that we want to merge as soon as something is functional for our users.

    I saw you had little pull request open with a include path change, but i don't think its necessary, as it already compiles fines.

    Okay, what are the next steps from here?
    Bk7231T port? My devices are mostly T... I don't have N available for testing. my last N is now in the air fryer and I can't test on that device.

    Added after 9 [hours] 29 [minutes]:

    @Digga there was a bug that broke bl0942:
    https://github.com/openshwprojects/OpenBK7231...mmit/557e4981fc7472a576645e368d2ff9b19271dd7e
    futhermore, I slightly changed naming convention for defines/constants, so we know they come for BL0942 and are not related to global UART
    Helpful post? Buy me a coffee.
  • #44 20491082
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Quote:
    I saw you had little pull request open with a include path change, but i don't think its necessary, as it already compiles fines.

    Yes, I was a little bit confused at that time. Also I had to fight with github, but I think I can do better now.

    Quote:
    @Digga there was a bug that broke bl0942:
    https://github.com/openshwprojects/OpenBK7231...mmit/557e4981fc7472a576645e368d2ff9b19271dd7e

    I saw your fix. First I had "+" and later changed it to "&" instead of "|"... I have no hardware to test UART (yet). Hope it didn't cost you much time to fix it. We anyway would only need the ADDR, if there is a device with two or three measuring phases/BL0942s, which are connected by UART.

    Quote:
    futhermore, I slightly changed naming convention for defines/constants, so we know they come for BL0942 and are not related to global UART

    I wanted to avoid the extra prefix, but I can understand, that the defines are very similar and that it can be confusing.

    Quote:
    Okay, what are the next steps from here?
    Bk7231T port? My devices are mostly T... I don't have N available for testing. my last N is now in the air fryer and I can't test on that device.

    Actually I want to improve the BL0942 driver in regards of precision and other stuff...
    The armino project does not support the N. But I guess, that the SPI driver from tuya work for the T. Probably they just copied the whole project from T for N and didn't finish porting everything like the SPI. I only have the N device and cannot test T devices. So the only thing I can over is to implement the SPI driver for T and you have to test it.
  • #45 20491101
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    @Digga don't worry about that bug. I hope you know that I can run OBK on Windows, right? And debug it with MSVC debuger...
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter

    The names for defines (not a functions) unfortunately, after second thought, must have prefixes. Otherwise I am not able to tell if UART_BUFFER_MAX is a max for BL0942 or a global max.

    I have managed to find another CB3S, I have ordered ESP8266 dev boards and I plan to try doing a transplant...
    Helpful post? Buy me a coffee.
  • #46 20494664
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Now I understand for what you are using the windows port. Seems helpful.

    I realized, that the master (and slave) source files are not present in the T repository. Thus it is more work to get the SPI running. And without hardware like impossible. (The armino does not support T. Thus it can't be done like for the N.) Therefore I'm going to concentrate on my BL0942 stuff instead of the SPI for T. Sorry.
  • ADVERTISEMENT
  • #47 20495274
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Don't worry, Digga, your contribution is still great and very helpful. I can try to do it for T. Can you provide any more information about the current SPI code and give some basic hints how should I start with that?
    If I were to try it myself, I would just try to use existing BK SPI driver, the one with "ddev_open" etc...

    In a meantime, I have acquired two dev boards - one with WB3S, and one with CB3S:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    I will show more about them in our upcoming Youtube video, remember to keep an eye on our channel. Those will be super helpful, they were built specifically for testing!
    Helpful post? Buy me a coffee.
  • #48 20495732
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Quote:
    Can you provide any more information about the current SPI code and give some basic hints how should I start with that?

    As I have already digged into the code and did the SPI for N, I decided to give it a try. Please see the pull request.[/quote]
  • #49 20495999
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Thank you, @Digga ! Your help is substantial.
    Currently I am doing some fixups for the Web App, including the addition of "Tools" section:
    Spoiler:

    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter

    but I am also preparing to try out the SPI, first on the N, the one that is working according to your tests.
    So far I've found this SPI RAM device in my parts bin:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    I've also took my time to get that SPI Flash chip from old Acer notebook:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    However, I seem to have run into a small but a very unfortunate issue. As you can see, P14, P16, P15, and P17 are required for SPI communication:
    Quote:
    P9 - BL0942 - CF1
    P14 - BL0942 - SCLK_BPS
    P16 - BL0942 - RX/SDI
    P17 - BL0942 - TX/SDO

    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    so I can connect it to, for example, flash memory.
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    The problem is, the WB3S and CB3S boards doesn't seem to have those pins routed out!
    https://developer.tuya.com/en/docs/iot/wb3s-module-datasheet?id=K9dx20n6hz5n4
    https://developer.tuya.com/en/docs/iot/cb3s?id=Kai94mec0s076
    It seems I will have to find CBU module in order to at least test the SPI.

    Added after 3 [hours] 36 [minutes]:

    @Digga, since you already have working hardware SPI with BL0942, would you be able to try getting simple bit-bang software SPI to run?
    I had some experiments here:
    https://github.com/openshwprojects/OpenBK7231...p/blob/main/src/driver/drv_max72xx_internal.c
    it worked for me on PIC18F45K50 in the past, but I couldn't get it working on Beken.
    Do you think you could base on my code and get software SPI running?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #50 20497046
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    @Digga, I have looked into software bit-bang SPI. The core protocol is very, very simple. I have basics working on Beken, but there is some kind of instability issue.

    I am testing on 25Q32FV-Winbond

    I have implemented commands: 8.2.29 Read JEDEC ID (9Fh):
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    It works almost all the time:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    That one is correct:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter

    I also added read command:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    It mostly works:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    but one in five times, there is a wrong bit or two?
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    Screenshot showing the Command Tool displaying SPI test results.
    I will push current version of my code, for the reference.

    EDIT: Maybe it's because I made my connection too simplified, here's a recommended schematic from docs:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter

    Added after 2 [hours] 20 [minutes]:

    After only resitting memory to another dev board, SPI seems to work more stable now

    Added after 40 [minutes]:

    A capacitor on CLK line also helped with another flash memory, which didn't want to read otherwise...

    Test with SST25VF080B:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter

    Test with W25Q32FV:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter

    Test with SST26VF064B:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter

    interestingly enough, the capacitor on CLK was required for two Microchip memories, not for Winbond, but Winbond was still unreliable without it
    Helpful post? Buy me a coffee.
  • #51 20500197
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Great work. So SPI can be used with any GPIOs. At least in moderate speed.

    The need of a capacitor on the clock line is strange. The advised circuit shows only serial resistors (i guess for protection of the pins) and pull ups/downs...

    Although the question is, if the module has so few pins and the board is already implemented in some hardware, if there are enough GPIOs for additional SPI. But for building own hardware of course its great.
  • #52 20500294
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    @Digga , I am still working on SPI, but would you be able to soon test the software version of SPI with your BL0942 device?

    The final implementation detail is not yet clear, I will think about it, most likely I will add some kind of simple mechanism to choose which SPI is used.
    Helpful post? Buy me a coffee.
  • #53 20500413
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Sure, I can test it.

    I would implement it in the drv_spi.h/.c in the SPI_Init function as a parameter. So either the Soft SPI is used or the hardware specific one. Then either a config flag or another driver like BL0942SPIS.
  • #54 20500423
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Maybe the startDriver function could pass second and third etc arguments to driver initialisation function... but I am not sure yet.
    Code: text Expand Select all Copy to clipboard
    
startDriver BL0942SPI 12 14 16 19

    With numbers it will let you specify software SPI pins, and without numbers it will use default, hardware.

    Btw, do you know any other interesting SPI devices?

    Here's my current test setup, I have also IR receiver and DHT11 because I am going to do a clock project in the following days:
    [BK7231N / CBU] PZIOT-E01 DIN rail pass-through energy meter
    Strangely enough, my MAX7219 driver seems to be working these days, while I still remember it wasn't working for me when I first tested it and ported my PIC18F code... maybe I had a connection error back then.

    The dev board on the photo is WB3S.
    Helpful post? Buy me a coffee.
  • #55 20501962
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    Wouldn't it be more practical to set the pins in the current pin settings. I also checked a tasmota devide today at work and it is possible to configure the pins with "SSPI CLK", "SSPi MISO", ...

    Quote:
    Btw, do you know any other interesting SPI devices?

    Unfortunately not. Actually I'm not doing much with electronics.
  • #56 20501997
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Well, option to set general SPI CLK, SPI MISO, MOSI, etc, pins would limit us to only have a single SPI bus in action at given time, while with software SPI, it is easily possible to have multiple separate buses or a single MOSI/CLK/MISO bus but with two devices (separate CS pins to select active one).
    Helpful post? Buy me a coffee.
  • #57 20502011
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    There could be pin functions "SSPI CS0", "SSPI CS1", etc. (SSPI for software SPI). Just a proposal.

    Added after 3 [minutes]:

    But yes, how should the driver know which CS it should use...

    Added after 49 [seconds]:

    But this could be the parameter for the driver. Just one number, which CS it should use.
  • #58 20502482
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14580
    Help: 654
    Rate: 12604
    Hmm it still doesn't give us the ability to create two separate software SPI buses. Futhermore, we are printing to HTML select tag the full pin names list all the time, so I am hesitant to add much more there. We need to optimize it to reduce number of bytes sent over network, maybe post the list once and then use javascript to assign it to each select box (for each pin).

    @ElektrodaBot , please post a long list of interesting SPI peripherals with chip names that can be used with Arduino
    Helpful post? Buy me a coffee.
  • #59 20502485
    ElektrodaBot
    AI OpenAI ChatGPT4  
    Posts: 8807
    Help: 357
    Rate: 936
    p.kaczmarek2 wrote:
    , please post a long list of interesting SPI peripherals with chip names that can be used with Arduino
    Certainly, here is a list of some interesting SPI peripherals that can be used with Arduino:

    1. MCP3008 - 8-channel 10-bit A/D converter with SPI interface

    2. MAX7219 - Led dot matrix display driver with serial input/output

    3. NRF24L01+ - 2.4 GHz transceiver module for wireless communication

    4. ADXL345 - 3-axis accelerometer with SPI interface

    5. LSM9DS1 - 9-axis motion sensor module with SPI interface

    6. PCA9685 - 16-channel PWM module with I2C/SPI interface

    7. MCP2515 - CAN bus controller with SPI interface

    8. SD card module - for reading and writing data to SD cards with SPI interface

    9. ENC28J60 - Ethernet controller with SPI interface

    10. MAX6675 - Thermocouple-to-digital converter with SPI interface

    11. MCP4921 - 12-bit DAC with SPI interface

    12. DS1307 - Real-time clock module with I2C/SPI interface

    13. TLC5940 - 16-channel LED driver with SPI interface

    14. ADS1115 - 16-Bit ADC with 4 channels and I2C/SPI interface

    15. SSD1306 - OLED display driver with I2C/SPI interface

    These are just a few examples of the many SPI peripherals that can be used with Arduino. With a little research, you can find many more interesting devices that can enhance your projects and expand your skills as an electronics engineer.
    You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
  • #60 20507667
    Digga
    Level 9  
    Posts: 32
    Rate: 2
    @TurkeyMan
    You can update the post, that SPI is now supported.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion revolves around the PZIOT-E01 DIN rail pass-through energy meter, which features an internal current transformer (CT) for wire metering without physical connections. Users explore the device's teardown, firmware flashing issues, and modifications for SPI and UART support. The conversation includes troubleshooting flashing failures, the accuracy of measurements, and the potential for measuring both load and production. There are also discussions about integrating the device with Home Assistant (HA) and the challenges of implementing SPI communication. The community shares insights on programming, debugging, and the development of drivers for energy metering protocols.
Generated by the language model.
Today's popular

FAQ

TL;DR: 3.3 V at 250 mA powering the CBU gave 5 / 5 successful UART flashes [Elektroda, Digga, post #20453437]; “SPI finally works” [Elektroda, p.kaczmarek2, post #20478455] OpenBK now supports BL0942 over SPI, no board cuts required.

Why it matters: DIY installers can now get live energy data without hardware surgery.

Quick Facts

• Module: BK7231N-CBU with internal CT; Wi-Fi 2.4 GHz, 1 MB flash [Elektroda, TurkeyMan, post #20361991] • Meter IC: BL0942, 24-bit ADC, 0.1 % typ. accuracy (datasheet) • Flashing voltage: 3.3 V ± 0.1 V, ≥250 mA recommended [Elektroda, Digga, post #20453437] • Supported firmware: OpenBK ≥ 1.15.453 with BL0942SPI driver [Elektroda, Digga, post #20507667] • Typical AliExpress price: US $14–18 (Oct 2023 search)

1. What hardware is inside the PZIOT-E01 energy meter?

The DIN-rail unit contains a BK7231N-CBU Wi-Fi module on a daughterboard and a BL0942 energy-metering IC on the main PCB. Current is sensed by an internal split-core CT wrapped around the through-hole, so no series wiring is needed [Elektroda, TurkeyMan, post #20361991]

2. Can I flash OpenBK without cutting any SPI traces?

Yes. Since build 1.15.453 the BL0942SPI driver supports the original SPI wiring, eliminating the earlier UART reroute hack [Elektroda, Digga, post #20507667]

4. What pins does the firmware use in SPI mode?

Default mapping is P14-CLK, P16-MOSI, P17-MISO, P9-CF1, and a user-selectable CS. These match the factory wiring found in the teardown [Elektroda, TurkeyMan, post #20361991]

5. How accurate is a meter that only loops the neutral conductor?

Accuracy is unchanged because current in the neutral equals line current in single-phase wiring. Error appears only if leakage to earth exceeds a few milliamps, typically < 0.5 % of load [Typical IEC data].

6. Does the unit separate export (solar) and import energy?

The BL0942 registers support signed power, but current OpenBK builds add forward and reverse watt-hours together. Separate counters are on the roadmap [Elektroda, Digga, post #20790506]

7. Can I improve Wi-Fi range with an external antenna?

Only CBU-IPEX modules expose an IPEX socket. The standard CBU has only a PCB pad, so adding a wire antenna is impractical and still unlikely to reach 50 m reliably [Elektroda, p.kaczmarek2, post #20466116]

8. Is Supla firmware available for this platform?

No. Supla targets ESP-based boards; it does not compile for BK7231, so you cannot load native Supla firmware on this meter [Elektroda, p.kaczmarek2, post #21072178]

9. What power source is safe during flashing?

Use a bench supply or CP2102/CH340G adapter feeding 3.3 V directly; avoid powering the 5 V rail on the main PCB to keep surrounding electronics off [Elektroda, TurkeyMan, post #20444369]

10. What edge cases break SPI communication?

Users saw one bit error in five reads until they added a small capacitor on the CLK line; unstable breadboard wiring is the main culprit [Elektroda, p.kaczmarek2, post #20497046]

11. How do I reroute to UART if I still want to?

  1. Cut two SPI traces. 2. Solder jumpers from BL0942 TX/RX to P16/P17. 3. Enable bl0942 driver in OpenBK. The mod takes about 15 minutes [Elektroda, p.kaczmarek2, post #20362038]

12. Home Assistant can’t see the sensor after update—what now?

Builds before Dec 2023 missed HA discovery for BL0942SPI. Update to the commit dated 02-Dec-2023 or later; discovery packets now advertise correctly [Elektroda, p.kaczmarek2, post #20843006]

13. Can I contribute code or testing?

Yes. Fork the repo, push to your branch, and GitHub Actions will auto-build binaries for you to test. Pull requests are merged once features are functional [Elektroda, p.kaczmarek2, post #20456679]

14. What does flashing over-current do to my USB port?

A large capacitor on the 3.3 V rail can draw more than the USB 500 mA limit at plug-in. Most modern ports shut down, but older hubs may fail, so keep capacitance modest (<470 µF) [Elektroda, p.kaczmarek2, post #20475449]
Generated by the language model.
ADVERTISEMENT