W końcu przyszedł mi wemos D1 mini i zmontowałem tak jak w schemacie który podałem wyżej i niestety nie działa. Co mogę jeszcze źle robić?
Wg schematu, który podałeś wyżej podłączasz 5V na GPIO. Więc prawdopodobnie uszkadzasz to wejście nieodwracalnie. Moim zdaniem schemat jest błędny. Należy użyć napięcia 3,3V, tego wymaga bezwzględnie ESP! Nie przeszkadza natopmiast w działaniu PZEM.
Nie wpadajmy w panikę, kiedyś Espressif twierdził ponoć, że UART w MCU ESP8266 jest odporny na logikę TTL (inne GPIO z pewnością nie)
Niestety nie dokopałem się do źródeł, ale wiele rozwiązań, w których traktowano moduł ESP-01 jako “modem WiFi” zdaje się potwierdzać ten fakt.
Obecna dokumentacja zabrania podawania poziomów powyżej 3,6V na wejścia, ale to jeszcze nie znaczy że mamy upalony układ (na szczęście są tam rezystory pullup, a nie bezpośrednie zwarcie z 5V).
Moim zdaniem nie działa, bo tu jest błąd:
GPIO1 ma być podpięte do RX a GPIO3 do TX
RX i TX w/g schematu z tego posta
I druga sprawa, jeśli używasz tego samego wsadu co dla ESP-01 a masz Wemos D1 (lub klona) to musisz od nowa zdefiniować piny (bo użyłeś inne) skoro to Tasmota to ogarniasz to z GUI, a jeśli np. ESPHome to kompilujesz nowy wsad.
Lub ewentualnie zostawić te same (tyle, że na krzyż, bo wcześniej źle łączyłeś ESP-01) WeMos ma GPIO1 opisane jako TX i w związku z tym łączysz je z RX w PZEM (i analogicznie GPIO3 to TX więc łączysz z RX PZEM)
Wemosa podłączyłem zgodnie z tym poniżej:
Mam wgraną tasmotę i zmieniałem te RX z TX i też nie działa
No cóż masz tam kontrolki LED więc widać na oko czy jest jakakolwiek komunikacja.
Masz święta na dokształcanie i dalsze testy.
Jeśli będziesz chciał wyrzucić lub połamać (gdyby nie działało) to ja chętnie przyjmę tą elektronikę nie zwracając uwagi czy to już elektro-śmieci (za darmo, pokrywam koszty przesyłki lub odbiorę osobiście), niestety nie czuję się na silach zdalnie “ciągnąć za rękę”.
Skoro planowałeś ESP-01 to pewnie masz mostek UART-USB - możesz go wykorzystać do wstępnej diagnostyki.
Jeśli to twój pierwszy projekt na ESP/Tasmota, to może spróbuj na początek coś prostszego. Czy w ogóle wgrałeś pełną wersję Tasmoty i w wersji posiadającej funkcje, które potrzebujesz?
Jeśli nie czujesz Tasmoty, to jest też projekt ESPHome (jakkolwiek tam trzeba samodzielnie sobie projektować co chcesz zbudować, w zamian za to własnoręcznie zbudowane firmware może być bardziej elastyczne od TAsmota)
Tasmota ma wbudowaną konsolę, więc raczej wszystko będzie widać.
@wrobi wybierz prawidłowe ustawienie dla GPIO. U mnie było D2 i D1 w przypadku innej płytki ale najważniejsze dla Rx przypisz konfigurację PZEM016 Rx (98)
tu może być szczegół, który ma znaczenie.
I jak teraz sobie przypominam mnie zmylił, bo do wyboru jest również logicznie PZEM004 Rx
.
Szkoda, że nie załączasz więcej informacji. Właśnie zrzutu z okna konfiguracji GPIO modułu czy nawet zdjęcia testowanego sprzętu na stole.
Podłącz układ zmieniając tylko pin w Wemos D1 mini z 5V na ten z 3,3V.
Tak, tutaj miałem błąd. dodatkowo wgrałem tasmotę 8.5.1 bo miałem 12.2.0 i nie chciało ruszyć. Dzięki wielki za pomoc
Nie poddaje się tak szybko. Tasmota jest łatwiejsza niż ESPHome. Pomimo to mam kilka urządzeń na Tasmocie i ESPHome. Z tym sobie nie potrafiłem poradzić ale dzięki pomocy @Cezary.K projekt zakończony sukcesem. Także nie połamię płytki i nie wyślę do Ciebie @szopen
Oprogramowanie PTVO pozwala na zbudowanie własnego urządzenia Zigbee.
Więc dlaczego nie spróbować ożenku PZEM-004 V3.0 w połączeniu z CC2530.
Podczas konfiguracji wsadu hex
dla CC2530 zapisujemy plik potrzebny do dodania obsługi naszego urządzenia w Z2M.
Robimy to zgodnie z dokumentacją projektu Zigbee2MQTT:
C.D.N.
Z ciekawości sprawdziłem czy program do tworzenia plików wsadowych hex
FirmwareConfig od ptvo zadziała pod moim Linuxem Mint. Do uruchomienia windowego pliku/aplikacji .exe
jest w Linux oprogramowanie Wine.
O dziwo to działa i nawet tworzy pliki wsadowe hex. Hura może nie będę musiał odpalać laptopa z Win - pomyślałem.
A było to tak…
Po ustawieniu wyjść pod 3szt PZEM z ich adresami przechodzę do zakładki Expert
Po uzupełnieniu opcjonalnych nazw itp., zapisuje plik potrzebny do stworzenia urządzenia DiY w Z2M, a następnie klikam przycisk Save na dole okna i mogę zapisać gotowy plik hex dla mojego CC2530.
Jakże prosto i przyjemnie
Więc sprawdzę, czy wygenerowany plik hex zadziała z CC2530.
Tylko nie Win jak pomyślę, że mam ponownie odpalić laptopa z Windows… gdzie wcześniej mordowałem się z instalacją Start SmartRF Flash Programmer od Texas Instuments dla ich programatora CC-Debuger, to mnie skręca na samą myśl. Straciłem zbyt dużo czasu przy zakładaniu konta na ich stronie, uwierzytelnianiu, wydawaniu zgód. Następnie dawno nie odpalany Windows zaczął usilnie instalować aktualizację systemu itp itd… Wolę mojego Linuxa i dwie komendy z konsoli:
sudo apt install cc-tool
cc-tool -e -w /home/cezary/Pulpit/Zigbee/pzem/pzem3f.hex
Teraz czas na dodanie urządzenia DiY do z2M.
Paruję uruchomiony moduł CC2530 jak każde inne urządzenie Zigbee pozwalając jedynie na dołączenie do sieci. Udanie ale z komunikatem o nieobsługiwanym urządzeniu.
W następnym kroku sprawię, że urządzenie zostanie rozpoznane przez Z2M.
Na początek umieszczam wcześniej zapisany podczas konfiguracji wsadu dla CC2530 plik .js
w katalogu z konfiguracją Z2M
//data/data/com.termux/files/home/zigbee2mqtt/data
W samym pliku konfiguracyjnym Z2M configuration.yaml
dodaje wpis z odesłaniem do nazwy pliku .js
mojego urządzenia:
external_converters:
- pzem3f.js
Zapisuję zmiany i restartuję Z2M. Reszta zadzieje się automagicznie.
Po odłączeniu zasilania CC2530 przestaje nadawać, ale bramka dalej pokazuje ostatnie dane i ciągle je zapisuje do historii.
Sensownie byłoby aby dane były zerowana i w tej postaci zapisywane do historii. Oczywiście z pominięciem zerowania zużytej energii.
Jak rozwiązać ten problem?
Chyba chodzi o parametr availability
. Czy ktoś bardziej biegły może wytłumaczyć jak powinna być skonfigurowane ustawienie dla raportowania dostępności urządzeń?
Cześć, zbudowałem powyższy zestaw z CC2530. Skompilowałem ustawienia w PTVO, wgrałem plik .js do DEV3 i dodałem wpis do C. Jednak nie pojawiła się poprawna struktura I/O którą utworzyłem w PTVO (Ustawiłem pod kilka czujników i PZEM).
“Status: Obsługiwane”
“Stan: {}”-czyli brak
W podglądzie urządzeń Sterowanie pokazuje wszystkie I/O które posiada CC2530:
Sterowanie: L1,L2,L3,L4,…,L16 i Sensory: L1,L2,L3,L4,…,L16
Jednak nie ma wyróżnionych wybranych przeze mnie w PTVO.
Jak naprawić ten problem?
Sprawdziłem też przypadek, w którym wybieram w kompilatorze PTVO tylko sam PZEM, ale sytuacja jest identyczna z opisaną powyżej.
A kupiłeś licencję dla swojego sprzętu?
szopen, możesz rozwinąć ten wątek?
Kontrolnie zapytam, czy zmieniałeś adres w każdym z 16 PZEM’ów?
Czy sprzętowo, od strony magistrali UART masz to wszystko ogarnięte? Zasilanie, sygnały na diodach impulsowych, pull up…
Mam podpięty tylko jeden PZEM i w pod jeden output został skonfigurowany w kompilatorze.
Więc nie rozumiem skąd masz L2…L16.
Powyżej pokazałek każdy z kroków przed i po kompilacji.
Jedyne o czy nie wspomniałem, to o potrzebie podpięcia P0.3 do RX w PZEM.
Wersja demo ma ograniczenia, nie wiem czy ich nie przekroczyłeś
https://ptvo.info/zigbee-configurable-firmware-features/premium/
Czy komuś udało się rozkminić jak zerować zmienną która powinna być odebrana z PZEM, ale z powodu np. odłączenia zasilania CC2530, niepotrzebnie utrzymuje starą wartość?
Obecnie testując działanie PZEM zdarzyło się, że transmisja padła, ale licznik w bramce dalej sumował zużytą energię która była nieaktualna.