openHAB [Rozwiązany] Zmiana bitów w ramce modbus

Co do komunikacji z innego softu do obu "na raz"

Czytanie rejestru F03 z modułu ID3 i modułu ID7

Zastanawia mnie jedna rzecz

Dlaczego deklaracja mostu dla id7 nie zakłóca pracy z id3

Bridge modbus:tcp:DIO "DIO Bridge" [ host="192.168.xx.xxx", port=4196, id=7] 

ALE deklaracja poller już powoduje błąd komunikacji z id3

konfiguracja ID7

Bridge poller DIStrych "DIS" [ start=129, length=16, refresh=1100, type="holding" ] 

Konfiguracja ID3

Bridge poller PkStrych "PKS" [ start=1, length=16, refresh=500, type="holding" ]

 

Czy w takim razie problemem może być samo OH?

Wróciłem wreszcie do domu...

Podmiana konwertera też nic nie dała.

Obstawiam błąd od strony programowej.

Żadnej literówki czy znaku niepożądanego nie znalazłem 😭

@szpila86 Proponuję założyć ticketa dla MODBUS binding OH.

@kamikac 

Pechowy kwartał z czasem ;(

Spróbuję jeszcze coś pokombinować ale na chwilę obecną wysypał się mi influx i przechodzę na OH4

Polecam konfig w plikach i dane w mySQL.

Do tego oczywiście backupy 😀

Odświeżę kotleta.

Była chwila jak to z końcem roku i podłączyłem licznik zamiast wejść i ruszyło bez problemu - super pewnie Pan Chińczyk coś zepsuł w płytce z wejściami.

Licznik 1F łączy się bez problemu ma ID1 płytka z przekaźnikami ID3 ustawienia z portów pasowały nic nie trzeba było zmieniać, tabela z rejestrami dodana w pudelku no sytuacja idealna można by pomyśleć.

ALE....

Po jakiejś godzinie usłyszałem że roleta dyga co jakiś czas, e tam zdaje mi się. Wieczorem zaczęły się same poruszać czasem w górę czasem w dół!

 

Może to jednak kwestia konwertera?

Po dołączeniu magistrali od licznika wszystko wróciło do normy.

Macie jakąś sprawdzoną firmę nie koniecznie za tys zł 🫤

Testów ciąg dalszy.

Sprzętowo wszystko połączone z "terminatorami" testowane na różnych źródłach zasilania konwertera gdyby miały być jakieś zakłócenia....

Wystarczy że w OH wyłączę puller od ID1 to moduł ID3 zaczyna poprawnie działać, nie wzbudza się samoczynnie, komunikacja z nim wraca na zielono.

Podrzucę jeszcze raz konfigurację samych mostów, nie ma konfliktów nawet pullery inaczej się nazywają powinno śmigać a nie chce.

Bridge modbus:tcp:LicznikkWh_Strych [ host="192.168.xx.xx", port=4196, id=1]  {
    Bridge poller inputRegisters [ start=0, length=80, refresh=1000, type="input" ] {        
	}} 

Bridge modbus:tcp:Przekazniki [ host="192.168.xx.xx", port=4196, id=3] {
    Bridge poller PkStrych [ start=1, length=16, refresh=500, type="holding" ] {

       }
}   

Odpytywania modułów są w różnym czasie poza tym w 485 jest sprzętowe zabezpieczenie przed wzajemnym zakłócaniem komunikacji w sieci. Każdy z mostów oddzielnie działa razem nie w 99% ID3 komunikacja pada i pojawia się samoczynne wzbudzanie przekaźników czasem na ułamek sekundy czasem aż do następnego "ducha".

Nie zauważyłem żeby wzbudzenia były zsynchronizowane z pracą czegokolwiek i są losowe czasem co 3min czasem co 20sek. Długość skrętki między ID3, a konwerterem 10cm 😉 za to konwerter - ID1 to już 40cm ;D. ID3 i ID1 mają rezystory 120 choć chyba bezzasadnie przy takiej długości magistrali, masami spięte obecnie nie są pomiędzy sobą.

ID1 licznik kwh zasila sam siebie ID3 zasilanie z zasilacza impulsowego 12VDC konwerter To samo co ID3 było POE ten sam efekt.

 

kolejny konwerter na testach zlan 5143d efekt ten sam.

Może to wina softu modułu przekaźników? Ale skoro solo na magistrali działa....

Co jeszcze mogę? Bez sensu ;/

 

[ERROR] [ort.modbus.internal.ModbusManagerImpl] - Last try 3 failed when executing request (ModbusReadRequestBlueprint [slaveId=3, functionCode=READ_MULTIPLE_REGISTERS, start=1, length=16, maxTries=3]). Aborting. Error was I/O error, so resetting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketTimeoutException Read timed out [operation ID 85df160f-f35e-466b-802a-5413f5f739e0]

Dodane przez: @szpila86

↑

super pewnie Pan Chińczyk coś zepsuł w płytce z wejściami.

To by nie było wcale, a wcale zaskoczenie. 😉 Miałem raz sporo problemów z oficjalnym konwerterem wifi do inwertera Huwei. W końcu support odpisał że nie można zaraz po połączeniu TCP do dongla wysyłać zapytań, ponieważ połączenie ze stroną RTU może nie być jeszcze gotowe. Ten sam konwerter przy dwóch równoczesnych połączeniach TCP wysyłał odpowiedzi na zapytania 1 mastera do 2. I takie kwiatki były na sprzęcie od rozpoznawalnej chińskiej marki. Inna sugestia od supportu to było wymuszenie przerw pomiędzy zapytaniami.

Co do samego problemu - potrzebuję sprawdzić jedną rzecz, a mianowicie zarządzanie połączeniami po stronie OH. Trochę mnie dziwi to, że ta sama definicja thingsa raz działa a raz nie. Po sparsowaniu pliku i wczytaniu wszystko jest już takie samo.

@ldywicki 

Jestem otwarty na sugestie. Sprawdzałem analizatorem czy czasem nie ma jakiś większych zakłóceń żeby sama na nie jakoś reagowała ale nic.

Zamówiłem 2 płytkę niby taka sama ale ma nieco inną elektronikę i inny kolor dipswitch 😉 będzie za 2 tyg.

Przesyłka dotarła. Szybka podmiana i testy. Na chwilę obecną po 48h wszystko śmiga dziś może dołączę 3 moduł i zobaczę czy dalej będzie ok.

Czyżby powodem problemów był niedopracowany soft?

poniżej wrzucam foto z porównaniem modułów. Sprzętowo różnica kosmetyczna ale programowo.... wszystkie problemy znikły.

Skrypty w OH nie zmienione odpalone i od razu wszystko ruszyło i po prostu działa.

@szpila86 to, że płytka wygląda tak samo lub bardzo, bardzo podobnie nie znaczy, że producent jest ten sam. Chiny to królestwo kopii, więc bardzo często dobre produkty, które zyskują popularność są powielane z różnym skutkiem. Nawet kupując od tego samego sprzedającego na Ali, nie można mieć absolutnej pewności, że kolejna sztuka będzie taka sama jak poprzednia.

 

@ldywicki 

Wystarczy drobną zmiana w sofcie płytki...

Ale to takie upokarzające tyle czasu marnować wszystkim...