Nie musisz mieć “taki” konkretnie adapter. Sporo zależy co chcesz osiągnąć. Czy tylko podgląd parametrów i pozostawienie pokojowego sterownika czy pełne sterowanie za pomocą bramki OT. Tematów na forum było już o tym kilka:
To tak na podsumowanie wątku - szukając rozwiązania należy na wstępie się dzielić całą posiadaną dokumentacją, podejrzewam, że wielu z nas by zauważyło, że masz OpenTherm, a nie BSB nawet gdybyś wrzucił na wstępie coś tak biednego jak te 2 zdjęcia.
1 polubienie
@szopen masz rację.
Wracając do tematu to zależy mi aby sterować kotłem za pomocą regulatora IDA tak jak mam teraz, muszę tylko jakoś wykombinować podgląd parametrów w HA i sam podgląd mi wystarczy
Można np. zacząć szukać tak (bo już masz spasioną płytkę ESP32 z Ethernetem)
https://github.com/search?q=esphome+opentherm&type=repositories
Jeśli chcesz sterować swoim gotowym termostatem, to potrzebujesz jakiś gateway do OT a nie mastera w sieci
ten projekt jest chyba jakimś wstępem (tzn. może na jego bazie chyba coś odpalisz)
są inne projekty ze świeższymi aktualizacjami, ale nie chce mi się kopać który się potencjalnie nada do podsłuchiwania OT, a który jest tylko masterem i zastępuje twój termostat
ale większość gotowych projektów bazuje na obecnie przestarzałym (w sensie planowanego wycofania z produkcji) ESP8266
(ale nie wiem czy OT można “podsłuchiwać na bezczelnego” wpinając się tylko odbiornikiem w magistralę)
Jest też nawet jakiś gotowy projekt sprzętu bramki i ten zawiera zarówno mastera jak i slave i wpina się go pomiędzy termostat a kontroler pieca (więc należałoby poszukać czy jakieś projekty w miarę gotowego oprogramowania do niego pasują)
Edit - przejrzałem na świeżo specyfikację OpenTherm (jest w linku do tego projektu powyżej, w sumie kiedyś ją już widziałem, ale w ogóle nie utkwiła mi w pamięci, bo ani ja, ani nikt z bliskich znajomych nie ma sprzętu OT) i w skrócie
- jest to wybitnie specyficzna konstrukcja, bo zakłada dla kompatybilności ze starszym/tańszym/prostszym osprzętem 2 modele sterowania - dwukierunkowe przesyłanie danych (OpenTherm Plus, OT+ czyli ten “prawdziwy” OT) i zgodność z termostatami PWM (OpenTherm Lite, OT-), gdzie w ogóle nie są przesyłane żadne dane tylko nastawy przez procent wypełnienia PWM, oba rozwiązania jednak uwzględniają wykrywanie usterki w komunikacji/awarię pieca
- komunikacja w jedną stronę jest pętlą prądową, a w drugą poziomy napięć - dlatego interfejs musi mieć bardzo specyficzną konstrukcję
- interfejs jest niezgodny z wysokonapięciowym portem szeregowym, więc się nie da podsłuchać (a przynajmniej w prosty sposób)
- na linii mogą być tylko 2 urządzenia: master (termostat) i slave (piec), dlatego bramka musi mieć dwa przyłącza linii (master po stronie pieca i slave po stronie termostatu, bo dla pieca jest termostatem, a dla termostatu emuluje piec).
Wielkie dzięki za wyjaśnienie i pomoc.
przemyślałem to i doszedłem do wniosku że nie będę na razie podłączał kotła do HA,
jednakże zależy mi aby HA wiedział jakie jest ciśnienie wody w instalacji c.o. i muszę wykombinować czujnik moduł który ma wejścia analogowe bo ten mój “wypasiony” ESP32 takiego nie posiada.
Jak to nie posiada, posiada i to nawet dwa całkiem porządne przetrorniki ADC
(Analog to Digital Converte).
1 polubienie
Haha, właśnie miałem opierdzielić OPa za nieczytanie dokumentacji…
Wprawdzie wymaga to nieco pokopania (nawet nie wiemy która to wersja płytki)
ale gwarantuję, że na 40-pinowym złączu znajdzie się przynajmniej jedno przyłącze analogowego GPIO
MCU ESP32 jest pod tym względem bardzo elastyczny i aż 16 GPIO można skonfigurować jako Analog In czyli w trybie ADC (UWAGA nie każde można użyć - ESPHome na dzień dobry limituje użycie przetwornika ADC2, który jest w konflikcie z WiFi, ale ADC1 ma na większości płytek wyprowadzonych 6 multipleksowanych wejść).
Wprawdzie ta płytka Olimexa ma od groma już zajętych pinów na akcesoria które będą raczej zbędne, no ale… zaraz, zaraz - kto ją kupił? skoro wystarczyłoby wybrać jakąś tanią konstrukcję bez Ethernetu przewodowego (który jest prawdziwym pożeraczem GPIO).
Konkretniej widzę, że wyprowadzonych jest 6 analog-GPIO z tej puli, która jest zdatna do użytku (= wszystkie przy założeniu równoczesnego używania WiFi), jednak niektóre (może wszystkie, ale nie mam tyle czasu by się w to zagłębiać) mogą wymagać wylutowania zbędnych komponentów lub skorzystania z opcjonalnych mostków PCB (a raczej ich przecięcia, @mario026 masz w rękach - analizuj), nie mam takiej płytki w ręce wtedy analiza byłaby łatwiejsza, ale można sobie porzeźbić po schemacie.
PS
Tak szczerze mówiąc to w zupełności wystarczyłaby płytka prototypowa ESP32 typu “zupełny golas” (i to również do tego projektu BSB-LAN z samego początku, bo przewodowy Ethernet nie jest przymusowy, a zabiera mnóstwo zasobów z MCU, tylko zwykła płytka wymagałaby w BSB-LAN “połączenia na pająka”), no ale wybrałeś jeden z najwyższych modeli na rynku płytek prototypowych, który ma masę interfejsów w tym nie tylko ten nieszczęsny Ethernet, ale nawet CAN, dwukierunkowa podczerwień, magistrale I2C i SPI na osobnym złączu a bis na pokładzie są przekaźniki, ładowarka Li-po, gniazdo karty SD, oraz opcjonalne złącze 40-pinowe…
No moim zdaniem tą płytkę można spokojnie nazwać Bentleyem wśród płytek prototypowych ESP32… jeśli nie umiesz jej wykorzystać choć w ułamku możliwości to wystaw ogłoszenie, bo chyba szkoda pozbywać się z niej komponentów tylko dlatego, że ma ich za dużo.
Piny złącza EXT prowadzące do tych GPIO które mogą pracować jako ADC
na pierwszy rzut oka do analizy są warte
REL1 → wylut R1, tracisz przekaźnik REL1
REL2 → wylut R5, tracisz przekaźnik REL2
BUT1 → tniesz zworkę BAT/BUT1 na pozycji 1-2 (niebieska linia to linia cięcia), tracisz przycisk BUT1 (oraz opcję pomiaru napięcia akumulatora, która jest zamienna z przyciskiem), zalecam to rozwiązanie bo jest konstrukcyjnie przewidziane do modyfikacji
Więcej czasu zajęło mi pisanie niż sama analiza schematu, analizę pozostałych możliwości olałem, bo może przemyślisz zastosowanie tak spasionego sprzętu do bardziej ambitnego zastosowania… a sądząc po oznaczeniach też by wymagały wylutu komponentów.
Aha no i podstawa - skąd wiedziałem, że te piny brać pod uwagę?
Ponieważ wiem skądinąd (ale pisałem to wyżej), że w rachubę wchodzi tylko przetwornik ADC1 - ramki zielone, jeden pominąłem bo zauważyłem za małą ramkę po fakcie, to błąd przy rysowaniu - jest 6 multipleksowanych wejść
Natomiast ADC2 olewam, gdyż ADC2 jest w konflikcie z timerami WiFi - ramki czerwone, (ale nie tylko, bo uciąłem nieistotny fragment i się znalazły poza obrazkiem)
Sory że Ci zawracam głowę ale nie poradzę zlokalizować tego cięcia.
nie wiem czy mam rozlutować to poniżej?
To zrób wyraźne (ostre) zdjęcie, bo z tego to się nie podejmuję analizy (szczególnie, że istotny fragment zamalowałeś na niebiesko i nie widać dokąd prowadzą ścieżki ani co z czym jest zlutowane) ale - tak, chodzi prawie na pewno o ten obrysowany obszar, być może (no na 99,9%, bo zakładam że to fabryczne lutowanie, a nie twoje i opis zworki jest zgodny ze spodziewanym) wystarczy ściągnąć lut plecionką - masz lutownicę i plecionkę (albo chociaż odsysacz)?
Od biedy można się tego lutu pozbyć “metodą partyzancką” - podgrzać lutownicą do płynności i kantem płytki uderzyć w blat biurka (czy czegoś innego masywnego drewnianego, czego nie będzie szkoda).
Często tego rodzaju zworki są przygotowane w sposób jak na schemacie (nie wymagają lutowania w fabryce, ale za to przecięcie mostka jest trudne, jest to tańsze w produkcji więc nie mając płytki w ręce spodziewałem się właśnie takiego rozwiązania), wersja z kroplą lutowia jest łatwiejsza do konfiguracji przez użytkownika, bo użycie lutownicy jest o wiele prostsze niż cięcie przy takim zagęszczeniu ścieżek. (Więc tym większy szacunek dla producenta).
Płytka nie zgadza się ze schematem - numeracja złącza EXT się nie zgadza skreślenie, bo się zgadza
zrób więcej zdjęć bo trudno złapać orientację, ale to musi być to miejsce bo zworka jest opisana jak należy.
Jak widać ścieżka (docelowo docierająca do środkowego pinu zworki oraz do właściwego pinu MCU) jest po odwrotnej stronie, więc analizować musisz sam, bo przy takiej jakości zdjęć nie dam rady tego zrobić (zakładam, że płytka jest dwuwarstwowa, a nie np. czterowarstwowa). Ale zaznaczyłem twoje pole lutownicze gdzie będziesz miał wejście ADC po ogarnięciu zworki.
Tak mam lutownice i odsysacz, czujnik dotrze do mnie dopiero za kilkanaście dni bo kupiony na aliexpress.
tak wygląda po rozlutowaniu
tak mam w HA
esphome:
name: esp32-evb
friendly_name: ESP32-EVB
esp32:
board: esp32dev
framework:
type: arduino
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "P0JQ9ABVTs2Hd5BiLxwDXXXWOzjS3OEmYumDCDgh/As="
ota:
password: "a199729faec410fd3a84fb1ff33d48ed"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Esp32-Evb Fallback Hotspot"
password: "J4l8x5sMw8hH"
captive_portal:
binary_sensor:
- platform: gpio
name: "Ciśnienie w układzie c.o."
pin: GPIO4
Co muszę jeszcze dopisać aby zmienić to
state_class: measurement
unit_of_measurement: °C
device_class: temperature
friendly_name: ESP32-EVB Ciśnienie w układzie c.o.
na to aby pokazywało ciśnienie w bar a nie jak teraz w stopniach celciusza
Rozlutowane idealnie, można zmyć topnik spirytusem.
zauważ że ścieżka od środkowego pinu zworki idzie w 2 kierunkach do przelotek na odwrotną stronę PCB
w kwestii analizy PCB to miałem jeszcze parę uwag, ale wyprzedzasz bieg wypadków, a wartałoby sprawdzić czy nie popełniłem błędu
tu jak widać nie dałem rady analizować, bo plastik zasłonił to co ważne, a zdjęcie z innego kąta by pokazało co ważne (ale chyba możemy to olać - sprawdż tylko czy faktycznie dobrze oszacowałem połączenie środka zworki z polem lutowniczym 29 na EXT)
musisz zlokalizować która przelotka jest tą która łączy się ze ścieżką o lewej stronie płytki narysowana wstępnie na żółto
Co do kodu to jest mocno kontrowersyjny - szukałeś pinu z ADC, a zrobiłeś sensor binarny? i w dodatku na zupełnie innym GPIO? to na 100% nie będzie działać
dobra już widzę skąd wytrzasnąłeś GPIO4, ale RTC_GPIO4 znaczy coś zupełnie innego, w opisie jest to m.in. GPI34 (i to nie jest niekonsekwencja G= general, P = purpose, I = input, a O = output, a ten pin nie może być wyjściem! więc w opisie na płytce celowo nie ma litery I)
w dodatku GPI34 w terminologii stosowanej dla ESPHome to będzie GPIO34 lub po prostu 34
a co do samego sensora to chyba olałeś czytanie dokumentacji
po pierwsze to musisz mieć poprawny kod, a tym zajmiemy się później
i daj mi znacznie więcej czasu na pisanie odpowiedzi
Nie wiem dlaczego wcześniej nie chciało pójść to:
sensor:
- platform: adc
waliło błędem dlatego dałem
binary_sensor:
- platform: gpio
a teraz poszło.
czekam za czujnikiem
Bo miałeś zły numer GPIO? - konkretnie 4 zamiast 34, a walidator sprawdza oczywiste błędy przed kompilacją, w tym fakt czy dany pin może obsługiwać ADC czy nie, GPIO4 nie wspiera ADC (a przynajmniej w ESPHome, bo jak już 2 razy pisałem ADC2 robi konflikt z WiFi, więc jeśli sobie ogarniesz projekt w arduino bez użycia WiFi to być może dasz radę go wykorzystać, ale tego pinu nawet nie analizowałem, bo nie zamierzam sobie ani Tobie strzelać w kolano).
Pokaż notę katalogową tego czujnika.
W dodatku kupiłeś Bentleya z przewodowym Ethernetem, więc chyba warto by było zawalczyć o użycie karty Ethernet zamiast WiFi (bo sądziłem cały czas, że połączenie przewodowym Ethernetem jest główna motywacją w zakupie tak drogiej płytki).
Dla tego modelu płytki jest gotowy przykład do użycia
i jeszcze jedno ta płytka ma własną definicję aliasów, więc zamiast uniwersalnej definicji możesz (i może powinieneś) użyć dedykowaną, inne płytki Olimexa (nie wiem czy wszystkie) też mają własne definicje
esp32:
board: esp32-evb
framework:
type: arduino
dzięki temu masz takie definicje aliasów,
"BUTTON": 34,
"MISO": 15,
"MOSI": 2,
"SCK": 14,
"SCL": 16,
"SDA": 13,
"SS": 17,
oczywiście aliasu do przycisku już nie ma sensu używać, bo się go pozbyłeś, ale do pinów na obu magistralach (SPI i I2C) w tym mniejszym złączu możesz się odwoływać po aliasach (zgodnie z opisem złącza, bo tylko tam podpinasz tego typu sprzęt)
przykład - z tą definicją płytki
zamiast
pin: GPIO34
możesz użyć takiej konstrukcji (tyle że tam już nie ma przycisku)
pin: BUTTON
to jest czujnik
Hmm parę dni temu był wątek z bliźniaczym tematem, w opisie oferty sprzedawca się jakoś bardzo nie postarał, ale chyba ten twój czujnik ma w miarę identyczne parametry z tamtym z tego innego wątku.
z tego co mi utkwiło w pamięci to do pomiaru słupa wody się zupełnie nie nadaje, bo nie jest dobrany prawidłowo zakres pomiarowy, obawiam się że w twoim wypadku będzie podobnie (zakres pomiarowy nie powinien przekraczać spodziewanego najwyższego ciśnienia roboczego więcej niż ze 2x, a optymalnie gdy ono pokrywa się z zakresem pomiarowym).
W ogóle to ten wątek trzeba podzielić na przynajmniej 2 osobne (bo już totalnie odjechaliśmy tematyką od pierwotnej)