czwartek, 6 kwietnia 2023 o 09:28:29 UTC+2 heby napisał(a):
> On 06/04/2023 08:47, Dawid Rutkowski wrote:
> >> On 05/04/2023 20:26, Dawid Rutkowski wrote:
> >>> A ja masz zamiar generować tą "wtrącaną" ramkę?
> >> To mało istotne. Po prostu coś wrzuci jakieś zapytanie w środek bałaganu.
> > O tyle istotne - szczególnie w kontekście ew. gotowca - że musi skądś i przez coś
brać to dodatkowe zapytanie i analogicznie dawać odpowiedź.
> To może być np. wbudowane w urządzenie TCP->serial, albo osobny port
> RS485. Ten mój "master2" jes wirtualny, fizyczny, jakibądź.

Jakiś tam być musi, choćby guzik czy wyświetlacz (zależy czy chcesz wywołać akcję czy
pokazać odczytany parametr).
Bardziej chodzi o to, że integracja "gotowca" z jakimś UI przez ciebie wymarzonym
może być równie pracochłonna
jak zrobienie całości od początku.

> >>> W sumie nie wiem czy w modbus jest jakkolwiek zestandaryzowany multi-master...
> >> Nie ma, muszę go zrobić na kolanie.
> > Hmm, już modbus zapomniałem nieco, ale czy tam da się odróżnić ramkę
master->slave i slave->master po jej budowie?
> Da się, pamiętaj że to urządzenie "rozcina" przewód master<->slave.
> Urządznie wie, po której stronie przyszła ramka więc wszystko jest jasne.

To było rozważanie nie na sytuację "rozcięcia" tylko na próbę zrobienia multi-master
na jednej magistrali.

> > Jak umie rozróżnić to jeszcze pytanie, czy sprawdza zajętość magistrali czy
wysyła na pałę w interwałach.
> Pierwszy znak, który nadchodzi po stronie master1 natychmiast
> przekierowuje master2 do bufora. Kiedy komunikacja na master1 zostanie
> zakończona, master2 zostanie wysłany z bufora o ile coś w buforze jest.
> I symetrycznie w drugą stronę.

Przy "rozcięciu" jak najbardziej - wtedy masz 2 magistrale, a nawet 3 (tak jak i
milicjantów).
To sprawdzanie zajętości przez obecny master - twoje urządzenie X - jest potrzebne na
multi-masterze na jednej magistrali.

> Więc dziaął tu zasada "kto pierwszy, to do urządzenia, kto w trakcie, to
> do bufora".
> > Inaczej pozostaje tylko man-in-the middle i wnoszone opóźnienia, które mogą
uniemożliwić realizację.
> Sprawdziłem, sterownik jest bardzo tolerancyjny na opóźnienie a
> urządzenie odpowiada prawie natychmiast.

A jak częsta jest obecna komunikacja X<->Y?
Jest jakoś regularna?
"Man-in-the-middle" wymaga 2 (a nawet 3) RS-485, i uC - a oprócz tego pewnie jeszcze
komputer (chyba że dodana funkcjonalność ma być tak prymitywna, że do UI wystarczy
sam uC).
Multi-master na jednej magistrali dałby radę po prostu z komputerem.

do góry

On 06/04/2023 11:17, Dawid Rutkowski wrote:
>> To może być np. wbudowane w urządzenie TCP->serial, albo osobny port
>> RS485. Ten mój "master2" jes wirtualny, fizyczny, jakibądź.
> Jakiś tam być musi, choćby guzik czy wyświetlacz (zależy czy chcesz wywołać akcję
czy pokazać odczytany parametr).
> Bardziej chodzi o to, że integracja "gotowca" z jakimś UI przez ciebie wymarzonym
może być równie pracochłonna
> jak zrobienie całości od początku.

Docelowo to ma emulować TCP->MODBUS. Łącznośc po wifi. Tak że "master2"
to wirtualny port podpięty pod stos IP. Urządzenie będzie miało wobec
tego dwie dziury RS485: slave i master1 oraz jadną wirtualną master2, na
TCP.

A czytać z tego bedzie jakiś HomeAssistant. To bez znaczenia.

>>> Inaczej pozostaje tylko man-in-the middle i wnoszone opóźnienia, które mogą
uniemożliwić realizację.
>> Sprawdziłem, sterownik jest bardzo tolerancyjny na opóźnienie a
>> urządzenie odpowiada prawie natychmiast.
> A jak częsta jest obecna komunikacja X<->Y?

Rzędu 2 sek. Masa miejsca na wciśnięcie własnej.

> Jest jakoś regularna?

Tak.

> Multi-master na jednej magistrali dałby radę po prostu z komputerem.

Ale jest trudniejszy, bo wymaga sniffingu i odrobiny modlitwy jeśli
jednak pojawi się ramka urządzenia, które wysłało ją dla beki wcześniej
niż przewidziałem.

Interesuje mnie arbiter "rozcinający" połaczenie, jako podstawowa forma
tego urządzenia. To rozwiązuje sporo problemów elegancko, kosztem
zwiększenia czasu odpowiedzi w momencie "konfliktu".

do góry

czwartek, 6 kwietnia 2023 o 11:23:24 UTC+2 heby napisał(a):

> > Multi-master na jednej magistrali dałby radę po prostu z komputerem.
> Ale jest trudniejszy, bo wymaga sniffingu i odrobiny modlitwy jeśli
> jednak pojawi się ramka urządzenia, które wysłało ją dla beki wcześniej
> niż przewidziałem.

Stąd moje rozważania, czy urządzenie X ma taką funkcjonalność, że:
a) sprawdza czy magistrala jest wolna przed rozpoczęciem wysyłania
i jednocześnie
b) słucha wysyłanych przez siebie pakietów, by sprawdzić, czy nic się
w czasie nadawania nie wcięło i nie pokaszaniło komunikatu
czy też może
c) po prostu wysyła na pałę.

> Interesuje mnie arbiter "rozcinający" połaczenie, jako podstawowa forma
> tego urządzenia. To rozwiązuje sporo problemów elegancko, kosztem
> zwiększenia czasu odpowiedzi w momencie "konfliktu".

Oraz groźby całkowitego padu komunikacji między X a Y w przypadku padu arbitra.
Oczywiście komputer włączony jako drugi master w multi-master na jednej
magistrali też może komunikację pokaszanić, ale tylko wtedy, gdy zacznie
wysyłać bełkot albo padnie w czasie, gdy TXE jest załączone (no na to
można dać attiny żeby pilnował max. czasu jednego nadawania).

Ogólne pytanie, co się stanie, jak X przestanie widzieć się z Y - i vice versa?
Zapewne nie jest to reaktor jądrowy, ale kłopoty mogą się pojawić.

do góry

On 06/04/2023 11:56, Dawid Rutkowski wrote:
>>> Multi-master na jednej magistrali dałby radę po prostu z komputerem.
>> Ale jest trudniejszy, bo wymaga sniffingu i odrobiny modlitwy jeśli
>> jednak pojawi się ramka urządzenia, które wysłało ją dla beki wcześniej
>> niż przewidziałem.
> Stąd moje rozważania, czy urządzenie X ma taką funkcjonalność, że:
> a) sprawdza czy magistrala jest wolna przed rozpoczęciem wysyłania
> i jednocześnie

Wątpię.

> b) słucha wysyłanych przez siebie pakietów, by sprawdzić, czy nic się
> w czasie nadawania nie wcięło i nie pokaszaniło komunikatu
> czy też może
> c) po prostu wysyła na pałę.

Wysyła na pałę, to zwykły Elfin EW11 ale ze zmienionym przez producenta
firmware (zgłasza się inna nazwa accesspointa i zahaślone wifi niż w
stockowym, kupowanym w sklepie). Bez względu na to czy da się coś z tym
zrobić - urządzenie nie bazujace na świadomości mastera będzie
bezpieczniejsze.

>> Interesuje mnie arbiter "rozcinający" połaczenie, jako podstawowa forma
>> tego urządzenia. To rozwiązuje sporo problemów elegancko, kosztem
>> zwiększenia czasu odpowiedzi w momencie "konfliktu".
> Oraz groźby całkowitego padu komunikacji między X a Y w przypadku padu arbitra.

Tak, ale to nie steruje granatnikiem. Jak padnie to najwyżej nie będę
miał mało ważnego sterowania i monitoringu.

> Ogólne pytanie, co się stanie, jak X przestanie widzieć się z Y - i vice versa?
> Zapewne nie jest to reaktor jądrowy, ale kłopoty mogą się pojawić.

Będę marzł ;) No chyba, że zejdę piętro niżej.

To nic specjalnie skomplikowanego, przemysłowego czy cokolwiek z tej
ligi. Ale tak sobie pomyślałem, że taki "arbiter" z buforowaniem to
rzecz, któa mogła by być przydatna nie tylko mi. Masa urządzeń na rynku
ma RS485 i wyjątkowo gówniany sterownik, którego najczęsciej nie da się
zespolić z własnym IoT, tylko trzeba używać dziadowskich mechanizmów
producenta.

do góry

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

> Wysyła na pałę, to zwykły Elfin EW11 ale ze zmienionym przez producenta
> firmware (zgłasza się inna nazwa accesspointa i zahaślone wifi niż w
> stockowym, kupowanym w sklepie). Bez względu na to czy da się coś z tym
> zrobić - urządzenie nie bazujace na świadomości mastera będzie
> bezpieczniejsze.

Hmm, skoro wyszło w końcu, że ten X to żaden "sterownik" (zapewne pieca),
tylko jakaś taka dokładka umożliwiająca ustawianie i odczyt parametrów przez wifi,
to możesz to sobie w całości zastąpić, zamiast kombinować z multi-masterem czy
man-in-the-middle
(oczywiście dla innych przypadków może to nadal mieć sens).

Ciekawostka że to w oryginale konwerter "wifi<-RS485", a ma AP, a nie klienta wifi
(chyba że może oba - no cóż, ja mam konweter wifi<->RS232C, który ma tylko
klienta)...

Zakładam więc, że jak odepniesz ten X to Y nadal będzie działał, tylko bez zdalnego
ustawiania i odczytu temperatury, bo Y - piec - ma wbudowany sterownik.
Skoro komunikacja po modbus rozczajona, to możesz albo zmienić soft w tym EW11,
albo podłączyć ESP + konwerter RS485 - i będzie wifi.
Odpada problem multi-master - a reszta oprogramowania do integracji z własnym HA
dokładnie taka sama.

Czy jednak jest jakaś inna zasadzka?

do góry

On 06/04/2023 13:45, Dawid Rutkowski wrote:
>> Wysyła na pałę, to zwykły Elfin EW11 ale ze zmienionym przez producenta
>> firmware (zgłasza się inna nazwa accesspointa i zahaślone wifi niż w
>> stockowym, kupowanym w sklepie). Bez względu na to czy da się coś z tym
>> zrobić - urządzenie nie bazujace na świadomości mastera będzie
>> bezpieczniejsze.
> Hmm, skoro wyszło w końcu, że ten X to żaden "sterownik" (zapewne pieca),
> tylko jakaś taka dokładka umożliwiająca ustawianie i odczyt parametrów przez wifi,

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.

> Ciekawostka że to w oryginale konwerter "wifi<-RS485", a ma AP, a nie klienta wifi

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.

> Zakładam więc, że jak odepniesz ten X to Y nadal będzie działał, tylko bez zdalnego
> ustawiania i odczytu temperatury, bo Y - piec - ma wbudowany sterownik.

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

> Skoro komunikacja po modbus rozczajona, to możesz albo zmienić soft w tym EW11,
> albo podłączyć ESP + konwerter RS485 - i będzie wifi.

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.

> Czy jednak jest jakaś inna zasadzka?

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.

do góry

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

> 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.

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.

do góry

On 06/04/2023 14:47, Dawid Rutkowski wrote:
> 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?

Nie ;)

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

> Wtedy wystarczyłby sniffer zapamiętujący stany rejestrów w Y odczytywane przez X,
> odchodzi problem nadawania multi-master.

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

> Albo zapewne oprócz odczytu chcesz też mieć możliwość wysyłania komend.

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

do góry

czwartek, 6 kwietnia 2023 o 15:47:26 UTC+2 heby napisał(a):
> On 06/04/2023 14:47, Dawid Rutkowski wrote:
> > 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?
> Nie ;)
>
> Brakuje około 1/3 rejestrów w których znajduje sie bardzo ważny dla mnie
> parametr.
> > Wtedy wystarczyłby sniffer zapamiętujący stany rejestrów w Y odczytywane przez X,

> > odchodzi problem nadawania multi-master.
> Mam tak zrobione teraz. Podpięty jestem pod modbusa i sniffuję wlasnym
> kawałkiem kodu ramki zwrotne.
> > Albo zapewne oprócz odczytu chcesz też mieć możliwość wysyłania komend.
> To też. Kontrola jest drugim waznym elementem. Obecnie mam możliwośc
> przez applkę producenta, ale ja chcę to zautomatyzować z HA.

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ć.

do góry

On 06/04/2023 16:09, Dawid Rutkowski wrote:
> 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".

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.

do góry