Multiplekser/sniffer/arbiter modbus

Thu Apr 06, 2023 2:33 pm   

On 06/04/2023 13:45, Dawid Rutkowski wrote:

Z tego sterownika korzysta inna osoba "w internecie" w celu analizy
stanu, przez aplikację dostarczoną przez producenta.

Mam wyjscie:
1) Tylko apliakcja producenta (i brak automatyzacji)
2) Tylko moje HomeAssistant (i brak wglądu przez inną osobę)

A ja chcę obie.


To działa tak:
1) Elfi resetujesz. Zamienia się w AP o konkretnej nazwie i ustalonym haśle.
2) Apliakcja wie jak się z nim połaczyć.
3) Aplikacja rekonfiguruje go do *twojej* sieci wifi
4) Apliacja (prawdopodobnie) wrzuca mu nakaz połaczenia się ze swoimi
serwerami/chmurą
5) Masz dostęp przez chmurę

Tam jest w środku bardzo duzop opcji do konfiguracji, dostęp przez panel
www, emulacja tcp->rs485, udp->rs485, jakieś vpny, autonomiczne
czytanie. Masa tego. Mam stockowy, gdzie mogę sobie pogrzebać po
konfiguracji i jest przytłaczająco bogata.

Ale w tym dostarczonym nie mogę. Zarówno AP jak i sama komunikacja po
konfiguracji jest szyfrowana, a jak patrzysz jakie ma otwarte porty po
podłaczeniu się do mojego wifi - to nie ma. Jest wyłacznie inicjującym
połaczenie z własną chmurą.

Pewnie częsciowo mógłbym zdekompilować aplikację w poszukiwaniu hasła
wifi, ale samo zdekompilowanie w celu znalezienia rejestrów mnie już
dobiło - takiej sieczki nie piszą nawet hindusi. Najwyczajniej mi się
nie chce, ponadto wątpliwe jest czy dzięki temu uzyskałbym cokolwiek.


Ma. To tylko "sterownik chmurowy". Ma poza tym, normalny, fizyczny panel
kontrolny gdzie wszystko co chcę da się ustawić.


Tak, ale stracę zewnątrznego obserwatora. Podczas awarii okazało się, że
ten "zewnątrzny obserwator", a konkretnie firma instalująca w/w
urządzenie, obserwujac parametry pracy, rozczaił w czym problem.

Nie chce mu dawać dostępu do mojego HomeAssistanta, ponadto on nie da
wiary że poprawnie je obliczam/wyświetlam.


Nie ma zasadzki. Zwykłe hobbystyczne wyzwanie, którego nie da się
obronić biznesowo. Coś jak kupowanię wędki za 1kzł kiedy w sklepie dorsz
mrożony za grosze.

Thu Apr 06, 2023 2:47 pm   

czwartek, 6 kwietnia 2023 o 14:34:02 UTC+2 heby napisał(a):


Nie no, zasadzką jest to, że ten obecny X jest potrzebny, a przynajmniej przydatny.
Zaś Y zapewne drugiego portu modbus nie ma.

No to dla podtrzymania rozmowy zadam jeszcze jedno pytanie,
które pewnie już przemyślałeś - czy nie wystarczy ci odczyt parametrów,
które i tak monitoruje ten X?
Wtedy wystarczyłby sniffer zapamiętujący stany rejestrów w Y odczytywane przez X,
odchodzi problem nadawania multi-master.
Choć pewnie nie starcza, może za rzadko pyta, może nie o wszystko, o co byś chciał.
Albo zapewne oprócz odczytu chcesz też mieć możliwość wysyłania komend.

Thu Apr 06, 2023 3:47 pm   

On 06/04/2023 14:47, Dawid Rutkowski wrote:

Nie ;)

Brakuje około 1/3 rejestrów w których znajduje sie bardzo ważny dla mnie
parametr.


Mam tak zrobione teraz. Podpięty jestem pod modbusa i sniffuję wlasnym
kawałkiem kodu ramki zwrotne.


To też. Kontrola jest drugim waznym elementem. Obecnie mam możliwośc
przez applkę producenta, ale ja chcę to zautomatyzować z HA.

Thu Apr 06, 2023 4:09 pm   

czwartek, 6 kwietnia 2023 o 15:47:26 UTC+2 heby napisał(a):

Tak sądziłem.
Jedno, co mi przyszło na myśl, to inna organizacja tego "arbitra"..
Zamiast karuzeli z przekazywaniem ramek - która i tak się może skończyć padem
komunikacji przy awarii arbitra - może zrobić coś w rodzaju mirrora,
czyli urządzenie z trzema niezależnymi RS485 - ew. jeden z nich "wirtualny".
Jeden RS485 do komunikacji z piecem, drugi RS485 do komunikacji z EW11,
a trzeci dla siebie.

Trzymać w pamięci mirrora komplet rejestrów pieca - oczywiście jak najczęściej
odświeżany - i udawać piec i dla EW11 i dla "siebie".
Czyli jak idzie odczyt z EW11 to od razu mirror od razu odpowiada kopią ze swojej pamięci,
tak sam jak idzie odczyt od "siebie" - a do pieca w tym czasie lecą zupełnie inne komendy
odczytu w kółeczku odświeżania.

No jedynie jak będzie zapis to trzeba przerwać kółeczko odświeżania i ten zapis zrobić.

Thu Apr 06, 2023 4:19 pm   

On 06/04/2023 16:09, Dawid Rutkowski wrote:

Zastanawiałem się nad tym na początku, czy nie zrobić emulatora. Ale tak
sobie myślę, że tak arbiter byłby bardziej uniwersalny.

Ja w ogóle nie wiem, czy go zrobie. Ale jak zrobie, to byłby open source.

Wolałym aby producenci tych urządzeń mieli pojęcie o tym co się dzieje
na rynku home automation. Ale chyba nie mają. Stąd te chmury, pralki z
nfc, lampki na bluetooth i inne bezużyteczne guano na rynku "smart".
Depresyjne klimaty.

Thu Apr 06, 2023 4:36 pm   

czwartek, 6 kwietnia 2023 o 16:19:36 UTC+2 heby napisał(a):

Robią dla przeciętnego użyszkodnika, a nie dla fanów open source.
I pewnie im się sprzedaje.

W sumie taki arbiter to prosta rzecz - niewiele więcej niż np. konwerter prędkości RS
(sam robiłem na Atmega164, więc platforma na bogato - ale choć wygląda to prosto, to trzeba było do różnych
systemów dodawać różne sztuczki, żeby dobrze działało - a najlepszą w tym temacie
rzeźbę widziałem na dwóch AT89C2051 - a może nawet to było AT89C1051U - które
odebrane bajty przekazywały sobie równolegle 8-bitowym portem poza, jak
zwykle, "jedną raną stanowczo śmiertelną" - bo wracamy do tematu "gotowca",
czyli tego, jak zrobić interefejs do niewiadomego.
Czy ten arbiter ze strony powiedzmy TCP ma wyglądać jak abstrakcyjny model pieca?
Może oprogramowania HA mają takie "abstrakcyjne" modele - nigdy nie wnikałem,
więc kto wie, sam robiłem abstrakcyjny model źródła promieniowania laserowego...

Thu Apr 06, 2023 4:53 pm   

On 06/04/2023 16:36, Dawid Rutkowski wrote:

Arbiter w ogóle nic by nie wiedział o typie urządzenia.

Wykrywał by ramkę modbusa, buforował i odsyłał na inny interfejs w/g
jakiegoś prostackiego priorytetowania. Może nawet ze zmianą parametrów
transmisji, jak ktoś się uprze.

Coś w rodzaju switcha ethernet store&forward.

Uniwersalność jest od osiągnięcia.

Thu Apr 06, 2023 5:24 pm   

czwartek, 6 kwietnia 2023 o 16:54:04 UTC+2 heby napisał(a):

Uniwersalny oznacza zwykle "do niczego konkretnego się nie nadający" (dziś wyczytałem, że kacapy
wymyśliły "uniwersalny" reaktor jądrowy VVER-TOI - no to będzie znowu źle...).

Bo wciąż pytam o to, jaki chcesz mieć interfejs po TCP.
Czy:
- konwerter TCP<->RS485
- wysyłacz/odbieracz ramek modbus
- abstrakcja urządzenia wg schematu używanego przez jakiś system HA

No i jeszcze jedno mi przyszło do głowy - co z ramkami wysyłanymi przez y, czyli piec?
Przecież na 100% nie wiadomo, komu odpowiada.
Wysyłać do obu masterów?
Do tego, który ostatnio nadał ramkę?
Pamiętać, o co który pytał?

Thu Apr 06, 2023 6:49 pm   

On 06/04/2023 17:24, Dawid Rutkowski wrote:

Nie przesadzajmy. Switch ethernetowy jest uniwersalny, czy przerzuca
dane z Hubbla, czy pornole, wszystko jedno.


Standardem jest to najgłupsze rozwiązanie: TCP->RS485 bez jakiejkowliek
formy, bazujące tylko na timeoutach. Uważam jest za najgorsze, ale z
jakiejś przyczyny jest "profesjonalne" i już na tej grupie kiedyś
dowiedziałem się, że mam z tym nie dyskutować bo przemysł wybrał jak
zwykle to najgłupsze ;)


Wiadomo:

1) wysyłam ramkę od master1 (master2 czeka w buforze z blokadą)
2) slave dopowiada, przesyłam do master1, zwalniam blokadę

albo:

1) wysyłam ramkę od master1 (master2 czeka w buforze z blokadą)
2) slave nie odpowiada po określonym w konfiguracji czasie.
3) zwalniam blokadę nie odpowiadajac master1, on też sobie zrobi timeout
sam z siebie


Do tego, który jest obecnie uznany za rozmawiajacego. To określony slot
czasowy, określany przeze mnie.


Nie trzeba. Timeout w master jest zazwyczaj przesadnie duży, a timeout w
slave zazwyczaj absurdalnie krótki. To daje przestrzeń na implemetancję
normalnego, konfigurowalnego timeoutu w arbitrze.

Fri Apr 07, 2023 6:00 pm   

czwartek, 6 kwietnia 2023 o 18:49:09 UTC+2 heby napisał(a):

Ale sam ethernet to za mało na zrobienie newsa na usenecie czy też przesłanie zdjęcia - czy to galaktyki w Andromedzie czy też czegoś innego w innej Andromedzie.


A w ogóle da się zrobić modbus RTU na konwerterze RS485?
Coś podejrzewam, że ten EW11 to coś wyżej jednak, np. konwerter modbus TCP<-> modbus RTU.

I coś takiego byłoby przydatne w tym "arbitrze".

No bo "uniwersalność" upada, gdy chcemy konkretne zastosowanie i trzeba adaptować.
Niech będzie do jakiegoś HA.
Z czym to HA, którego używasz, współpracuje po TCP?
Z konwerterem na RS485 (multum ustawiania)?
Z bramką modbus TCP<->modbus RTU (sporo ustawiania)?
Z urządzeniem modbus TCP (też sporo)?
Z abstrakcją pieca (sporo rzeźbienia po drugiej stronie)?

Fri Apr 07, 2023 6:22 pm   

On 07/04/2023 18:00, Dawid Rutkowski wrote:

Bo tym zajmuje się zupełnie inna warstwa.


Tak.


Nie ma czegoś takiego jak "modbus TCP". Wysyłasz bajt do portu TCP i
wypada on po stronie RS485. Wpada bajt po stronie RS485 i wypada on z
portu TCP. Możesz taki konwerter "zrobić" na jednym poleceniu w Linuxie:
socat. Przez wiele lat miałem tak właśnie zrobione.

I to ze wszystkimi kosekwencjami tego kretynizmu braku opakowania. Jak
na przykład łamanie ramek TCP powodujące konfuzję i timeouty. Znowu
standard przemysłowy wymyślał ktoś bez pojęcia o sieciach.


Np. z innym EW11, sterującym rekuperacją. Ramki modbus są tworzone w HA
za pomocą stosowanego pluginu, ja okreslam jaki rejestr, jaki adres i
jakie ip:port i leci. Gołe bajty RTU. O, take:

modbus:
- name: recuperation
type: tcp
host: x.y.z.w
port: 8899
sensors:
- name: recuperation_gear
slave: 1
address: 4
scan_interval: 4

automation:
- alias: Set recuperation gear
trigger:
- platform: state
entity_id: input_number.recuperation_gear
action:
service: modbus.write_register
data:
hub: recuperation
unit: 1
address: 4
data_template:
value: ["{{states('input_number.recuperation_gear') | int}}",0]
[...]


EW11 w domyślnej konfiguracji jest dość prosty. Problem jak chcesz np.
automatyczne odpytywanie czy jakieś transporty, których nie sprawdzałem.


Nikt tego nie używa na poważnie. bajt tcp<->bajt uart jest "przemysłowym
standardem" ze wszystkimi konsekwencjami dziadostwa.

Jakoś kilka(naście?) lat temu była afera, że co więksi kretyni
wystawiali te zabawki do internetu, a mowa była o automatyce w dużych
obiektach przemysłowych.


Akurat abstrakcja pieca wymaga może z 50 linijek w pythonie. Nie
nazwałbym tego "sporo".

Ale to nie jest potrzebne. Arbiter nic nie wie o tym z kim się
komunikujesz. Ma tylko: baudrate, maksymalny timeout na odpowiedź i
maksymalny timeout między znakami. Te dwa/trzy parametry są
wystarczające. Skłaniam się nawet do tego, że sama wiedza "że to jest
modbus" jest zbędna. Dowolny, kompaktowy strumień bajtów, oczekujący
podobnej odpowiedzi, spełniajacy reguły timeoutu, się nada. Arbiter może
być jak switch - nic nie wie o danych.

Sat Apr 08, 2023 9:40 am   

On Wed, 5 Apr 2023 22:28:10 +0200, Piotrek wrote:

Moze od razu poprosic o kod na wybrany uC ? :-)


I to jest przykład z powyzszego archiwum, czy GPT napisal sam ?


J.

Sat Apr 08, 2023 4:07 pm   

piątek, 7 kwietnia 2023 o 18:22:32 UTC+2 heby napisał(a):

Jeśli jest, o co dalej pytałem.


Tylko trzeba mieć bardzo dobre połączenia.
Inaczej nie będzie się opłacało rozbierać po śniadaniu ;>


Jak nie ma jak jest - port 502 - i to nawet dwa.
Jeden bez CRC w ramce, "bo mają niższe warstwy", drugi z CRC, bo jednak niższe warstwy mają tylko sumy kontrolne.
Chyba że nikt nie zaimplementował (ew. tylko do bramek, a może i to nie).
Może więc czas zacząć?
Choć to dziwne jest, jakieś 4 bajty z przodu: Transaction identifier i Protocol identifier (ten zawsze 0) - nie wiem po co to może być potrzebne.


Ja wolę nc.


O to właśnie pytałem "czy się da".
Widać "da się", pod warunkiem że nie musi dobrze działać.
Albo np. leci modbus ascii a nie modbus RTU.


No to użyj.
Czy nikt nie zaimplementował?


Ale trzeba mieć pythona na tym urządzeniu, co robi abstrakcję pieca.
Jest na AVR?

Kiedyś dostałem do zabawy płytkę z renesas SuperH, z DRAM i złączem do kolorowego wyświetlacza po równoległym RGB.
Nie wiem, ile zapłacił za to ten, od którego to dostałem, ale soft to był interpreter TCL na eCos.
I podobno miało być tak, że będzie to umiał zaprogramować nawet tzw. grafik komputerowy...

Sat Apr 08, 2023 4:39 pm   

On 08/04/2023 16:07, Dawid Rutkowski wrote:

Abitera nie widziałem. Gotowych urządzeń implementujących raw RTU jest
od groma.

Niektóre idą dalej w tym szlaleństwie i są wersje UDP zamiast TCP.


Ta abstrakcja do niczego nie jest potrzebna w przypadku arbitera. Była
by uzyteczna, gdybym robił coś w rodzaju proxy. Ale nie wydaje mi się,
aby było to niezbędne. Arbiter jest ok, pod warunkiem, że przerwy w
komunikacji są statystycznie znacznie dłuższe niż transmisjie. U mnie
tak jest.


Python był jako wyznacznik minimum. Raczej narzęźbię to na C++.


Jestem raczej z daleka od "gotowców" o uproszczonej budowie. Skrajnym
przykładem jest LabView. Kolega w tym pracował zawodowo, robiąc bardzo
poważne rzeczy. Jego największym problemem refaktoringu nie było
programowanie, tylko jak przemieścić D'n'D kilka tysięcy elementów aby
dało się zmieścić pętlę i kilka drutów. Programowanie graficzne uważam
za znakomity żart, choc niewątpliwie wygląda świetnie na prezentacjach.

Innymi słowy, jesli to narzeźbię, to prawodpowodobnie na ESP8266 (ale on
ma niestety 1 i 1/2 uartu) albo ESP32. Tu nie ma wielkiego wyboru z
powodu komunikacji po wifi.

Swoją drogą: podobne urządzenie (do PV, ale tam są inne wymagania) od
kilku lat działa mi na teminalu Wyse Cx0 (normalny pecet wielkości 2
paczek papierosów) który kosztował mnie 20zł.

Sat Apr 08, 2023 4:40 pm   

On 08/04/2023 16:39, heby wrote:

Arbitra.