uruchomienie modbus w NeoGSM-IP-64

[tomekm85]

witam,
może ktoś pomoże. Mam zaznaczone w aplikacji (foto) a modbus nadal nie działa. Centrala NeoGSM-IP-64



Czy trzeba coś jeszcze zaznaczyć/włączyć?

[artur]

Hej!

Nie chcę Cie martwić ale obsługa Modbus na NeoGSM-IP-64 to ruletka (firmware 2.3).
Zasadniczo to nie udało mi się dowiedzieć kiedy to startuje i jaka jest kombinacja zdarzeń aby serwer Modbus działał stabilnie...

Integrowałem się na wiele sposobów w tym przez HomeAssistant / Modpool / Python / Go.
Dodam, że siedzę w tym temacie kilkanaście lat - wiem doskonale co to jest i jak to powinno działać.

Centrale odpytuję raz na 5 sek - częściej się bałem, że nie wyrobi procek.
Używam połączenia kablowego przez Ethernet / statyczne IP.
Centrala poki co nie ma karty GSM.

Generalnie problemy jakie zauważyłem:
1. W trybie serwisowym nie udało mi się nigdy podłączyć do centrali po Modbusie TCP.
2. Po rozłączeniu zworki serwisowej i bliżej nieokreślonej kombinacji restartów czasami serwer Modbus startuje od razu a czasami potrzeba zaczekac parę godzin ale to też nic nie oznacza ponieważ tak jak wstał tak samo znika i jest kompletnie nieprzewidywalny i niewiarygodny.
3. Obsługa błędów (w tym Modbusowych) to policzek w stronę użytkownika. W zasadziej jej brak albo jest z innej epoki (tak jak cała aplikacja z czasów Windows 3.11).
   M. in dlatego do dzisiaj nie udało mi się upgradeować centrali do firmware 2.5 przez kabel USB bo mimo, że ładuję wsad ściągnięty wcześniej z pliku to aplikacja się zatrzymuje z lakonicznym komunikatem, że identyfikuje bootloader (czy jakoś tak). Na laptoku jest oczywiście internet.
4. Sterowanie wyjść - mimo poprawnej flagi "Aplikacja mobilna RopamNeo/Modbus TCP/IP" na każdym wejściu zasadniczo to ustawianie stanu via Modbus po prostu nie dziala.
Tak zgadliście - nie ma żadnej informacji dlaczego.
5. W zasadzie brak jakiegokolwiek wsparcia technicznego w tym temacie bo widzę, że na forum (swoją drogą jego "silnik" pochodzi z... 2014 roku :D) rzadko się odpowiada i to raczej tylko na typowe i znane przypadki.

Postaram się na dniach przetestować rozwiązanie via MQTT - wszakże to push i chyba było trochę wcześniej niż ModBus w Ropamie.

Swoją drogą podziwiam odwagę firmy gdy reklamują to rozwiązanie do automatyki domowej...
Panowie - to lata świetlne za tym co oferuje np Home Assistant czy zwykły Domoticz.
Nie wspominając o fenomenalnym ESPHome.

Dodam, że mówię to bez cienia złośliwości - ot mam przypuszczenie, że cześć "programowa" to dzieło jednego człowieka i po prostu nie wyrabia na zakrętach z "nowościami" grzebiąc w kodzie pisanym w jakims C++ czy starym Delphi.
Jestem otwarty na merytoryczną dyskusję w tym temacie :)

[artur]

Sprawdziłem MQTT w NeoGSM-IP-64 i polecam tą wersję zamiast Modbus.
Chociażby to że przy zmianie stanu wejscia dostaje sie wiadomosc push i nie trzeba się recznie odpytywac co iles tam sekund...

[RobertH]

Obydwie integracje działają, przykłady integracji z HA na www,
oczywiście Modbus TCP a MQTT to dwa różne protokoły. Do testowania Modbus TCP jest prosty programik na PC
https://ropam.com.pl/wsparcie/product/modbus-tcp-ip/#download
https://ropam.com.pl/wsparcie/product/home-assistant/

[tomekm85]

@artur dzięki za odpowiedź, sprawdzę tego modbusa bez zworki, możliwe, że tu jest problem. Z modbusem mam do czynienia na co dzień (automatyka przemysłowa) i nie ukrywam, że to był główny powód, że zdecydowałem się na ropama - trochę mnie zasmuciłeś

@RobertH mam nadzieję, że masz rację i modbus będzie hulał (firmware v2.5). Proszę mi powiedzieć czy rzeczywiście jest tak jak pisał @artur, że działa on jedynie z wyciągniętą zworką "serwisu"

[RobertH]

...że działa on jedynie z wyciągniętą zworką "serwisu"

Nie chodzi o zworkę tylko tryb serwisowy, a on jest głównie po to aby programować centralę w sieci LAN.
A w czasie programowania via LAN inne usługi TCP nie działają m.in. aplikacja, modbus, mqtt

[tomekm85]

niestety zdjąłem zworkę trybu serwisowego i modbus nadal nie działa

[RobertH]

centralka w najnowszej wersji v2.5, przetestowane programem z www?

[tomekm85]

tak, centrala w wersji 2.5, manager w wersji 1.9.9 z zaznaczonym (foto), zwora serwisowa wyjęta, program do testowania ze strony ropam i modbas nie żyje

[RobertH]

Modbus TCP przetestowane - v2.5 z www, sprawdzone działa na porcie 502 (UDP), jednocześnie włączone MQTT
https://ropam.com.pl/wsparcie/wp-content/uploads/2019/09/neogsmip64_pl.zip

[tomekm85]

jednocześnie włączone MQTT

i może to jest rozwiązanie, ale sprawdzę to dopiero za 2 tyg. jak będę na budowie

[RobertH]

Modbus działa niezależnie od opcji MQTT, przetestowane na v2.5.
ps.
Temat do głębszej analizy: może w konfiguracji jest skrypt? Proszę wysłać na @ konfigurację i pamięć zdarzeń.

[Marcinus]

Zrobiłem u klientów kilka integracji po Modbusie na linii NeoGSM-IP-64 <-> Grenton Gate Modbus i podobnie, jak przy OptimaGSM nie notuję problemów.
Najdłużej działająca instalacja funkcjonuje bez uwag 13 miesięcy.

Oczywiście Grenton ma obsługę Modbus RTU i stosuję konwerter między Ropam a Grenton.
Jedyna uwaga: do stabilnej komunikacji potrzeba moduł LAN do NeoGSM-IP-64. Przy komunikacji przez WiFi co chwilę wyskakują błędy w odczycie rejestrów Modbus.
Przy zastosowaniu nakładki LAN (połączenie kablowe) odczyt rejestrów Modbus funkcjonuje bez błędów.

[Marcinus]

Sprawdziłem MQTT w NeoGSM-IP-64 i polecam tą wersję zamiast Modbus.
Chociażby to że przy zmianie stanu wejscia dostaje sie wiadomosc push i nie trzeba się recznie odpytywac co iles tam sekund...

Zgadzam się z Tobą Arturze - MQTT broni się samo - jest lepsze, wygodniejsze itd ...

... ale Grenton nie ma obsługi MQTT i obsługa Modbus w NeoGSM-IP-64 dla mnie jest jedyną sensowną możliwością integracji między tymi systemami.

Postanowiłem napisać w tym wątku, bo podkreślę raz jeszcze: nie miałem jednej integracji z Grentonem, tylko kilka i wszędzie miesiącami działa bez błędnych odczytów rejestrów. Świadczy to o stabilności implementacji Modbusa w centrali Ropam.
Większość rejestrów ustawiam na częstotliwość odczytu: około 1 sekundy.
Testowałem szybkość połączenia zaczynając na OptimieGSM i doświadczalnie ustaliłem ją na 9600 bps - szybkość wystarczająca a przy tym nie generująca błędów (przy większej prędkości pojawiały się błędy w odczycie)

W załaczeniu screen z bieżącego statusu konwertera między Modbus TCP a Modbus RTU: tu po zaniku prądu działa od 5 dni - na tyle przesłanych bitów "zero" błędów !
(centrala Optima GSM)