OpenBeken BL0937 Mod: Ulepszona dokładność/rozdzielczość dla odczytów niskiej mocy i monitorowania e

Stworzyłem nowy mod (fork) z innym podejściem do rozdzielczości i stabilnych odczytów do monitorowania mocy / energii z BL0937:
https://github.com/listen-obk/OpenBK7231T_App_BLtest

To podejście będzie działać tylko z układami monitorującymi moc wyjściową częstotliwości, takimi jak BL0937 i HLW8012.
Mój zamiar: Chciałem zmierzyć niskie obciążenia, takie jak zużycie wtyczki (drugi przykład). Nie mam pętli sterowania, w której wymagane są regularne szybkie aktualizacje, zamiast tego wolę dokładne i stabilne odczyty mocy / energii. Ten widelec został już wspomniany na stronie
https://www.elektroda.com/rtvforum/topic4114715.html#21745185], gdzie przedstawiono inne rozwiązanie.

Moje rozwiązanie:
Według karty katalogowej jeden impuls BL0937 reprezentuje nieco poniżej 0,5 mWh, co oznacza, że minimalna rozdzielczość dla mocy przy częstotliwości próbkowania jednej sekundy wynosi około 1,7 W. Ale nie potrzebuję aktualizacji co sekundę, a nie wyższej rozdzielczości, dlatego najpierw dodałem warunek "minimalna liczba impulsów przed aktualizacją", co oznacza, że w aplikacjach o niskiej mocy potrzeba kilku sekund, zanim pojawi się wystarczająca liczba impulsów do obliczenia mocy. Zmieniłem również bazę: liczba impulsów nigdy nie jest resetowana. W ten sposób żadne impulsy nie zostaną pominięte, jeśli nie zostaną uwzględnione w bieżącym cyklu, zostaną uwzględnione w następnym. Następnie zdałem sobie sprawę, że przy większej mocy nadal mam ten sam problem zbyt wielu aktualizacji i niestabilnych odczytów nawet przy stabilnym obciążeniu, więc dodałem kolejną opcję minimalnego i maksymalnego czasu cyklu. Aby to kontrolować, pojawiły się dwie nowe komendy:

BL0937_MinPulsesVCP <minPulses_V> <minPulses_C> <minPulses_P>
BL0937_IntervalCPMinMax <minInterval> <maxInterval>

Po zabawie z tym chyba najbardziej przydatna będzie druga komenda.
BL0937_IntervalCPMinMax <minInterval> kontroluje minimalny cykl aktualizacji w sekundach. Jeśli jest ustawiony np. na 10, wszystkie impulsy energii w ciągu 10 sekund są podsumowywane i moc jest obliczana na tej podstawie. Oznacza to coś w rodzaju sprzętowego uśredniania mocy (przynajmniej tak długo, jak wszystkie impulsy są przechwytywane przez procedurę przerwania). Brak zależności od częstotliwości próbkowania, krótkie skoki mocy nawet poniżej 1 sekundy będą uwzględnione z punktu widzenia energii, ale nie zobaczysz tych wysokich szczytów jako odczytu mocy.

Drugim wymogiem aktualizacji jest BL0937_MinPulsesVCP ... <minPulses_P> : jeśli minInterval osiągnięty, ale nie ma wystarczającej liczby impulsów minPulses_P , czekamy, aż zobaczymy ten limit liczby impulsów. Inny przykład: przy 0,25 W jest jeden impuls co 7 s. Dla dokładności chcę mieć co najmniej 2 impulsy - oznacza to, że wynikowy interwał będzie wynosił 14 s zgodnie z formułą arkusza danych. Jeśli obciążenie wzrośnie, interwał będzie się dynamicznie zmniejszał (dolny limit minInterval).

Dla niższych obciążeń, BL0937_IntervalCPMinMax <maxInterval> zacznie działać: jeśli minPulses_P nie zostanie osiągnięty w tym czasie, aktualizacja zostanie wymuszona.

Ponownie, skupiam się na jest na monitorowaniu mocy/energii, dlatego <minPulses_V> <minPulses_C> nie będą wyzwalać aktualizacji, tylko kontrolować przełączanie między pomiarami V i C. Pomiar V zwykle trwa tylko jedną sekundę, ale pomiar C może trwać dłużej. Wykonywana jest średnia dla obu pomiarów w cyklu (czas cyklu określony przez moc). Nie oczekuj wysokiej dokładności, ma to bardziej charakter informacyjny (wpływ na obliczenia współczynnika mocy).

Szczególnie przy długich interwałach interesujące może być szybsze rozpoznawanie zmian mocy (włączanie/wyłączanie grzałki). Aby to osiągnąć, dodałem kolejną komendę
BL0937_ForceOnPwrROC <rateofchange_W/s> <rateofchange_W/cycle>
<rateofchange_W/s> przeznaczony do skoków mocy (jak włączanie/wyłączanie grzejnika) i stałego obciążenia. Porównuje moc prądu z ostatnią sekundą. Jeśli dodatnia lub ujemna różnica jest powyżej limitu, odczyty są aktualizowane trzy razy (w kolejnych sekundach). Pierwsza aktualizacja będzie średnią mocą od ostatniej regularnej aktualizacji ( <minInterval> ), druga będzie miała rzeczywistą nową moc, ale czasami wolt/prąd nie są jeszcze poprawnie zaktualizowane.

<rateofchange_W/cycle> przeznaczony do obciążenia impulsowego (PWM) (sterownik 2-punktowy, taki jak grzejnik z termostatem). porównuje średnią moc bieżącego cyklu z mocą ostatniego cyklu i wyzwala jedną aktualizację i wyzwala trzy aktualizacje, jak powyżej.

Intencją jest ustawienie długich interwałów, np. średniej mocy powyżej 900 s, ale rozpoznawanie zdarzeń włączania/wyłączania z lepszą rozdzielczością czasową. Poprawi to dokładność zewnętrznego monitorowania energii.


Używam MQTT (z FHEM) do historii i kontroli i brakowało mi aktualnych wartości. Tasmota odpowiada aktualnymi wartościami przy zmianie i jeśli nie podano żadnych argumentów. Zaimplementowałem to samo dla nowych poleceń i dla BL współdzielonych poleceń VCPPublishIntervals, VCPPublishThreshold i VCPPrecision. Zachowanie musi być włączone przez inną komendę EnabeMQTTOnCommand 1 . To może być domyślne, ale chciałem być jak najbardziej kompatybilny.

Kompatybilność jest powodem innej komendy: BL0937_ScalefactorMultiply <factorV> <factorC> <factorP>
Surowe wartości V i P do skalowania i kalibracji są oczekiwane jako int w drv_pwrCal.c, ale dla lepszej rozdzielczości (P poniżej 1,7 W) wymagane są ułamki 1. Dlatego mnożę surową wartość (częstotliwość, V przez 10, P przez 1000) przed skalowaniem i stosuję niższy współczynnik skali (przesunięcie cyfry w porównaniu do głównej gałęzi).
Oznacza to, że jeśli oprogramowanie układowe zmieni się w stosunku do głównej gałęzi, wewnętrzne współczynniki skali muszą zostać zmienione. Aby zachować kalibrację, zwykle powinno to być BL0937_ScalefactorMultiply 0.1 1 0.001 .
Inną opcją może być BL0937_ScalefactorMultiply 0 0 0 . Jako rodzaj nowej funkcji spowoduje to zresetowanie kalibracji i użycie nowych wartości domyślnych. Po tym nowa kalibracja może być dobra.
Nie jest wymagane żadne działanie, jeśli urządzenie zostało początkowo sflashowane tym modem lub kalibracja nie została wcześniej wykonana.
Uwaga: przed ponownym flashowaniem do głównej gałęzi firmware, BL0937_ScalefactorMultiply 10 1 1000 należy wykonać, w przeciwnym razie wymagana będzie ponowna kalibracja.

Na stronie urządzenia polecenie pokaże aktualnie używane i domyślne wartości oraz zaleci mnożniki (10^x), aby zachować kalibrację. Notacja naukowa powinna pomóc dostrzec różnice.
przykładowy wpis w dzienniku:
Info:CMD:ts 5639 BL0937_ScalefactorMultiply: za mało argumentów do zmiany. Bieżące (domyślne) wartości V 1.248886E-01 (1.581335E-02) C 1.072063E-02 (1.287009E-02) P 1.280320E+00 (1.707145E-03), zalecane współczynniki 0.100000 1.000000 0.001000

Jeśli polecenie zostanie wysłane za pośrednictwem MQTT, odpowiedź będzie zawierać nowe współczynniki skali (lub bieżące wartości, jeśli polecenie zostanie wysłane bez argumentu).
Info:MQTT:P ublishing val 1.248886E-01 1.072063E-02 1.280320E+00 to ecr66000CFF9367/ScalefactorsVCP retain=0

Na koniec zastanawiałem się nad dokładnością czasu, ponieważ jest on używany do obliczania częstotliwości. W tym celu dodałem komendę SendTimestamps . Z wartością 1 będzie wysyłać NTP i wewnętrzne znaczniki czasu (diff) przez MQTT co godzinę. Idealnie różnica nie powinna zmieniać się w czasie. Jest to tylko ciekawostka, ponieważ częstotliwość jest w rzeczywistości uwzględniana w ogólnej kalibracji (współczynnik skali). Domyślnie jest wyłączona, włącz ją poleceniem SendTimestamps 1.

Chociaż jest to wersja testowa, istnieje kilka dzienników na poziomie debugowania i dodatkowego debugowania w celu sprawdzenia poprawności obliczeń (odpowiedzi na polecenia, tiki, impulsy, częstotliwość, ...).

Do tej pory mogłem testować tylko na najnowszych wtyczkach Tuya z ECR6600 i BL0937, które używają 2ms ticków. Byłoby wspaniale zobaczyć, czy działa (obliczanie częstotliwości) również na innych platformach.
Należy pamiętać, że ustawienia wyjścia VCPPublishIntervals i VCPPublishThreshold są dodatkowymi warunkami i mogą opóźnić lub uniemożliwić aktualizacje. Ten wariant może być czymś w rodzaju zamiennika dla VCPPublishIntervals.

Zapraszam do wypróbowania. Wszelkie komentarze na temat rozwiązania i nazw są mile widziane. Nie miałem żadnych problemów z OTA z i do głównych gałęzi/wersji powyżej 200 (kiedy zaczynałem). Należy wziąć pod uwagę tylko ScaleFactor, w przeciwnym razie EnergyStats może mieć szczyty lub luki, podczas gdy odczyty mocy są nieprawidłowe. Poza limitami bezpieczeństwa historii, nie ma żadnych zmian w tym kodzie. Od czasu do czasu synchronizuję fork, aby być na bieżąco z główną funkcjonalnością.

Wskazówka: podczas gdy jest to niestandardowe oprogramowanie układowe, na githubie przejdź do Actions, a następnie kliknij (ostatnie) pomyślne uruchomienie przepływu pracy, pobierz z sekcji Artifacts.

Bardzo ciekawy pomysł i wygląda bardzo obiecująco. Czy przy tym współczynniku skalowania moglibyśmy zintegrować go z głównym bez utraty kalibracji?

Ponadto, czy próbowałeś zweryfikować pomiary? Wziąć obciążenie rezystancyjne o znanej rezystancji, na przykład 0,25 W mocy, i sprawdzić odczyt? Następnie przejść do 1 W lub 0,1 W itd

Przepraszam, długa odpowiedź - krótkie odpowiedzi kursywą.

p.kaczmarek2 napisał:

Bardzo ciekawy pomysł i wygląda bardzo obiecująco. Czy z tym współczynnikiem skalowania można go zintegrować z głównym bez utraty kalibracji?

Tak
Tak. Automatycznie przyjmuje mnożenie współczynnika skali zdefiniowanego przez użytkownika (przez kalibrację). Zaimplementowałem to po komentarzu @divadiow na githubie.
Kilka uwag: funkcja log10() rozpoznaje pozycję przecinka dziesiętnego i ustawia mnożnik na podstawie zakresu (pow 10). Nie testowałem blisko limitów (takich jak 0,999 vs. 9,99 lub 1,0101 vs. 0,10101) z tym kodem C++ na platformie. Nie wiem, czy takie wartości istnieją w świecie rzeczywistym.

Kolejną otwartą kwestią są typy danych. Nie wiem czy na jakiejkolwiek platformie int ma coś innego niż 32bit. W przypadku ticks (timer) potrzeba 100 dni (na platformie ECR6600), aby zobaczyć przepełnienie. Podobnie jest w przypadku float, nie wiem, czy działa to tak samo na każdej platformie, w najlepszym przypadku wpływa to tylko na dokładność.

Nie mam doświadczenia z kodem wielomodułowym ani z githubem. Dlatego przejrzenie kodu (zmienne globalne vs. lokalne, formatowanie, nazwy,...) może być dobrym pomysłem.
W celu zapisania statystyk energii zmieniłem user_main.c, aby uzyskać dostęp do wskaźnika restartu, nie jestem pewien, czy można to zrobić w głównej gałęzi, czy też istnieje lepszy wskaźnik.
Nie wiem, co sądzisz np. o filozofii odpowiadania aktualnymi wartościami, jeśli komenda została wydana bez argumentów. Mogłaby to być ogólna flaga zamiast oddzielnej komendy, ale przypuszczam, że nie każdy programista będzie chciał zmieniać kod. Nie znam też wpływu na wszystkie przypadki użycia. Na razie starałem się, aby wpływ na inne moduły był jak najmniejszy. Niemniej jednak byłbym szczęśliwy, gdyby niektóre z pomysłów zostały zintegrowane z główną gałęzią (przez dowolnego współpracownika, nie chcę być autorem).

p.kaczmarek2 napisał:

Ponadto, czy próbowałeś zweryfikować pomiary? Wziąć obciążenie rezystancyjne o znanej rezystancji, czyli np. 0,25 W mocy i sprawdzić odczyt? Następnie przejść do 1 W lub 0,1 W, itd?

Brak walidacji z obciążeniem rezystancyjnym, ale sprawdziłem wiarygodność z różnymi urządzeniami. Posiadam 4 takie wtyczki i za pomocą jednej zmierzyłem pozostałe. Jeśli włączę przekaźniki, wartości są wiarygodne (3 wtyczki zwiększają się 3 razy w porównaniu do wykonania tylko z jedną). Dodatkowe zużycie dla jednego przekaźnika wynosi od 0,3 do 0,5W). Od wtyczki za 3 EUR nie oczekuję absolutnej dokładności w tym zakresie. Dla 0,1W masz jeden impuls co 17,5 sekundy zgodnie z arkuszem danych, podczas gdy kalibracja pokazuje >25% odchylenia od wartości z arkusza danych. Nie mam pojęcia z jakiego powodu. Formual w datasheet zawiera Vref z 1.218V - jeśli to usunę, wszystko jest w porządku. Albo fałszywe chipy, albo wersja datasheet nie pasuje do chipów we wtyczkach.
Jednym z urządzeń jest dla mnie wykrywanie stanu pralki i zmywarki. Różnica między "oczekiwanie w programie" a "zakończone, tryb gotowości" czasami wynosi <0.15W. Wartość bezwzględna (dokładność) nie jest zbyt ważna w tym przypadku. Następnym krokiem jest przetestowanie mojego urządzenia. Obecnie używam tasmota, ale tutaj rozdzielczość nie pozwala na wykrycie tego w stabilny sposób. Zawsze są jakieś zmiany w czasie. Niestety nie mam zapasowej wtyczki z BL0937 aby zmienić z tasmota na OBK tylko do testów.

Nie sprawdzałem przy niskim obciążeniu rezystancyjnym z dwóch powodów:
1. Nie mam jeszcze setupu, który pozwoliłby mi to zrobić na poziomie sieciowym (wkleić odpowiednie rezystory do wtyczki), czyli starałem się na razie uniknąć ryzyka.
2. Nie wydaje mi się to konieczne, ponieważ częstotliwość dla wszystkich trzech pomiarów jest liniowa . Dla tak niskiej mocy nie mam sprzętu do weryfikacji.

Co zrobiłem: skalibrowałem grzałką elektryczną 2000W (w rzeczywistości 1850W) i PZEM004-T do regulacji cos phi (do 1.000). Problem polega na tym, że jestem na sieci i dlatego napięcie jest dość niestabilne (wahające się między 228 a 239V). Podczas gdy rezystor jest mniej więcej stały (pewna zależność od temperatury), rzeczywista moc czynna zmienia się co sekundę w zakresie do 25W. Ufam tu matematyce - dla 2W oznacza to niedokładność rzędu 0,025W. Następnie zweryfikowałem z zasilaczem impulsowym laptopa Dell i obciążeniami rezystancyjnymi 70W i 40W. W ten sposób uzyskuję stałą moc czynną, ale współczynnik mocy jest poniżej 1 (zależy od klasy mocy zasilacza). Odchylenie wynosiło około 0,5W (w porównaniu do PZEM004-T, który ma błąd 1%). Zawsze występuje opóźnienie między pomiarami a odczytem. Ustawiłem pewną funkcjonalność w moim HA (FHEM) - odczyt PZEM004-T i zapis V, I i P do urządzenia wtykowego OBK za pomocą ustawionych poleceń w ciągu jednej sekundy, ale nadal występują odchylenia przy następnym odczycie.
Jako wynik końcowy uważam, że wartości są wiarygodne.
Niemniej jednak jestem ciekawy funkcjonalności i dokładności z innymi typami urządzeń.