Plugin do falownika Sofar HYD10KTL-3PH

Świetna robota @voyo.

Powiedz teraz jak powinien podłączyć falownik do RBPI ?

Zacisk 1 i 3 do:

A ta przejściówka do RBPi  i przez plugin ma działać ?

Tak, dokładnie. Zaciski A i B w falownika odpowiednio do tych samych stykow A i B (lub + i - ) .
W zależności od dlugości magistrali, czy jakis zakłóceń - może być. konieczność zaterminowania połączenia. (wygooglaj - terminacja RS485). W skrócie, to podłączenia opornika 120Ohm pomiedzy A -i B na początku u końcu magistrali.
Z doświadczenia - nie jest to konieczne przy krótkich i prostych połączeniach (jedno urządzenie komunikujące się z drugim).

Następnie odpalasz tego 'pośrednika' w komunikacji, coś co zamieni RS485 RTU na TCP ,  ja polecam tą aplikacje 'mbusd' (skonfiguruj odpowiednio plik konfiguracyjny), ale tak jak pisałem - powinny działać również rozwiązania sprzętowe (odpowiednio skonfigurowane).

Do opcji konfiguracyjnych, najważniejsze jest nazwa pliku urządzenia (np /dev/ttyUSB0 ), parametry komunikacji - standardowo to zwykle jest prędkość 9600bps, 8n1. Podobnie będzie wyglądała konfiguracja proxy sprzętowego.

Kolejnym istotnym parametrem do komunikacji jest adres (ID) urządzenia (w tym przypadku - Twojego Sofara), to sprawdzisz w parametrach na klawiaturze samego falownika, o ile pamietam o ile nie zmieniłeś  - domyślnie to '1' .

Tak skonfigurowane 'proxy' powinno umożliwić komunikacje z falownikiem z poziomu pluginu (lub dowolnego innego skryptu czy tez aplikacji). W konfiguracji pluginu należy podać odpowiednie wartości. u mnie wygląda to tak jak na załączonym obrazku.
Przypominam - używam w każdym ze swoich pluginów proxy TCP dla łączności modbus, być może , dla łączności z pojedyńczymi urządzeniami (1 do 1) będzie działać bezpośrednie połączenie po porcie /dev/ttyUSBxxx z poziomu pluginu, ale planuje zarzucić wsparcie dla tego typu łączności (nie jest stabilne, totalnie nie działa jeśli na magistrali jest kilka innych urządzeń, w moim przypadku do falownik, rekuperator,  pompa ciepła, 2 mierniki prądu , kilka termometrów , sterowanie roletami - wszystkie urządzenia na tej samej magistrali RS485. Pluginy poprostu nie zdążą odczytać wartości w swoich 10sekundowych cyklach z tych wszystkich urządzeń, a Domoticz nie ma możliwości "za-lokowania"  urządzenia dla pluginu na czas używania.

OK dzięki będę próbował. Plugin już mam w domoticzu:

Pytanie tylko jest opcja IP więc podaje IP Domoticza ?

IP miejsca, serwera , gdzie jest odpalony ten mbusd lub Twój sprzętowy 'proxy' do szyny RS485.

W moim przypadku to adres IP mojego RBPI, jesli uzywasz tego mbusd odpalonego na tym samym serwerze gdzie jest domoticz - to bedzie jego adres (lub. localhost - 127.0.0.1 )

Po podłączeniu tego konwertera USB -> RS485 pojawia mi się dwie opcje w Modbus Port:

Niestety obojętnie którą ustawię nie ma efektu.

Diody na konwerterze nie migają tylko podczas wpięcia do USB RBPI przez ok 2-3 sekundy dalej cisza. 

Adres ustawiony w Inwerterze 01. Mam jeszcze podłączony licznik ale na pinach 5 i 6.

Dodane przez: @voyo

↑

Następnie odpalasz tego 'pośrednika' w komunikacji, coś co zamieni RS485 RTU na TCP ,  ja polecam tą aplikacje 'mbusd' (skonfiguruj odpowiednio plik konfiguracyjny), ale tak jak pisałem - powinny działać również rozwiązania sprzętowe (odpowiednio skonfigurowane).

Ten krok nie wiem gdzie zrobić.

W przypadku konfiguracji pluginu do komunikacji po TCP , nie wybierasz juz urządzenia portu /dev/xxxxx , to pole zostawiasz puste.
I do wyboru masz albo własnie tryb TCP lub RTU.  RTU - w tej wersji pluginu jeszcze powinne działać, ale jak pisałem - zamierzam te wsparcie usunąć, nie będe tego rozwijał bo to ma sens tylko jeśli masz do obsługi jedno urządzenie, nie sprawdza się w bardziej rozbudowanej konfiguracji.

Więc - pozostaje, i polecam tryb TCP. 

Tak jak pisałem - potrzeba do tego czegoś więcej oprócz pluginu. Albo masz jakis sprzętowy konwerter RS485 na TCP, albo skorzystaj z tego narzędzia 'mbusd' o którym pisałem.

Opis instalacji i konfiguracji jest na githubie autora.
https://github.com/3cky/mbusd

voyo,
mam działający 'broker' pomiędzy falownikiem Sofar KTLX-G3 a serwerem mosquitto napisany w C.
komunikacja przez WIFI z loggerem LWS-3. Możesz podejrzeć mój kod:
https://github.com/michalzd/pvInverterBroker/tree/mqtt
w plikach /inverter/sofar.c i sofar.h  jest cała komunikacja z falownikiem Sofar. 

@michal-zd 
Dzięki. Czy bazowałeś na tym ? https://github.com/MichaluxPL/Sofar_LSW3
Zerknę później dokładnie na Twój kod, u mnie nie pasują mi wartości z kilku rejestrów, zobacze czy u Ciebie to jest ok.

Ale ogólnie - o ile podejście z uniwersalnym konwerterem/przekazywaczem do MQTT ma swoje zalety - 
(- to samo MQTT może obsłuzyć zarówno Domoticz, HomeAssistanta, nodeRed,  cokolwiekinnegojeszcze ,
 - teoretycznie upraszcza obsłużenie urządzenia w tym Domoticzu, bo nie wymaga dedykowanego pluginu, tylko zczytuje wartości z brokera MQTT )

ma też wady, i niedogodności - 
- używa nieudokumentowanej komunikacji z urządzenim które również nie każdy ma,
- jeśli ma, nie koniecznie będzie w tej wersji którą masz Ty i wspierasz (to mój przypadek, mam LSW3, ale w wersji firmware które nie działa z powyższym softem MichaluxPL, później sprawdzę ten Twój soft)
- łączność po TCP/IP jest wygodniejsza od RS485/Modbus, który jest owszem wolniejszy i bardziej wymagająca technicznie, ale Modbus jest jednak bardziej uniwersalny, i dodatkowo daje wgląd we wszystkie rejestry/sensory urządzenia
- wymaga kolejnego daemona/serwisu który ma działać  

Pozatym w dedykowanym pluginie do Domoticza, ogarniam wszystko od A do Z, dodawane są automatycznie wszystkie potrzebne urządzenia, (to powino być w zaletach dedykowanego pluginu 😉 )
największą wadą niestety , jest konieczność samodzielnego przygotowania wymagań potrzebnych do zadziałania pluginu - komunikacji/proxy po TCP do RS485. 

Ja, jako fan Domoticza - zdecydowałem że wolę podejście dedykowanego pluginu 🙂
(Dodatkowo, u mnie na tej samej magistrali RS485/modbus mam kilka(naście) innych urządzeń, które w ten sam, podobny sposób są obsłużone, mniejszy effort).

 @voyo

"Czy bazowałeś na tym ?  https://github.com/MichaluxPL/Sofar_LSW3 "
Nie. Pyton jest dla mnie średnio czytelny, nie jestem specem od Pytona, potrafi on czytać dane ze struktur binarnie?
Znalazłem w sieci specyfikację modbus i rozpiskę rejestrów dla Sofar Solar, w moim kodzie będą one również w pliku: 
https://github.com/michalzd/pvInverterBroker/blob/mqtt/inverter/Sofar.h
Znajdę ten plik ze specyfikacją, gdzieś go mam w dokumentach, podeślę ci.

Dodane przez: @voyo

↑

Ale ogólnie - o ile podejście z uniwersalnym konwerterem/przekazywaczem do MQTT ma swoje zalety

Oczywiście. 
Pierwszą wersję mojego sterownika miałem napisaną w jednym programie. Ze z względów na prostotę tworzenia UI w NodeRed postawiłem na uniwersalność. Tak powstał mój broker. Jest praktycznie gotowy do kompilacji w Linux na dowolnym sprzęcie. 
Aktualnie mam skompilowaną wersję na Raspberry Pi.  

Odniosę się do tez:

 - używa nieudokumentowanej komunikacji z urządzenim które również nie każdy ma,
   jeśli ma, nie koniecznie będzie w tej wersji którą masz Ty i wspierasz    

tak, ale problem jest zawsze od strony jakiegokolwiek urządzenia, broker nanosi na to warstwę abstrakcji i zwraca dane json zawsze takie same niezależnie od danych uzyskiwanych z innego falownika. 

- łączność po TCP/IP jest wygodniejsza od RS485/Modbus, który jest owszem wolniejszy i bardziej wymagająca technicznie, ale Modbus jest jednak bardziej uniwersalny, i dodatkowo daje wgląd we wszystkie rejestry/sensory urządzenia

To samo dostajesz poprzez TCP/IP. Protokół modbus jest niezależny od warstwy fizycznej, chociaż kojarzy się z RS485. 

-wymaga kolejnego daemona/serwisu który ma działać 

To nie problem, dzięki C zasobożerne toto nie jest. 

PS. Poprosiłem kolegę  Daro1003  aby sprawdził, czy w przypadku jego inwertera Sofar HY... również będą zgodne dane modbus.