Redirect via socat not working

Question

Redirect via socat not working

stephanritscher opened this issue a year ago · comments

I'm running iobroker on computer A and a second B with the usb serial connector.
On A, I run

socat PTY,raw,echo=0,link=/dev/ttySMARTMETER tcp:B:4444
```
and set device to /dev/ttySMARTMETER in ioBroker.smartmeter.

On B, I run
```
socat /dev/ttyUSB0,raw,echo=0 tcp-listen:4444,reuseaddr
```
Then ioBroker logs show `Error: No or too long answer from Serial Device after last request.` for the smartmeter instance.

**Expected behavior**  
ioBroker.smartmeter should be able to read meter values as if the serial device was connected to A directly.

**Versions:**  
 - Adapter version: 3.3.4
 - JS-Controller version: 4.0.24
 - Node version: v18.16.0
 - Operating system: Fedora Linux (A), Alpine Linux (B)

**Additional context**  
When connecting the usb serial connector to A, ioBroker.smartmeter can read out the meter values flawlessly.
I'm searching for any working (lightweight) solution for redirecting the serial communication via (local) network, not necessarily socat.

Ingo Fischer · Answer 1 · Thu May 25 2023 05:47:51 GMT+0800 (China Standard Time)

That depends a lot. How is your configuration in smartmeter?

Normally with socal you need to hard configure the baudrate - I do not see this in your parameters. This also means that it only works with SML because with D0 wthere is a baudrate changeover potentially which is not popssible with socat.

stephanritscher · Answer 2 · Fri May 26 2023 05:20:15 GMT+0800 (China Standard Time)

Thanks for the quick response!
My setup is with a SML (1.03/1.04) meter. I tried with empty settings for data transfer and explicitely setting the defaults to confirm I use the right values with socat below. I tried with using the symbolic link /dev/ttySMARTMETER or the explicit character device (e.g. /dev/pts/3) both entered via user defined device name.
I updated my commands based on your hint:
On A:

socat -d -d -v -b1 PTY,rawer,link=/dev/ttySMARTMETER,b9600,cs8,cstopb=0,parenb=0 tcp:B:4444

On B:

socat -d -d -v -b1 /dev/ttyUSB0,rawer,b9600,cs8,cstopb=0,parenb=0 tcp-listen:4444,reuseaddr

My thoughts:

-d -d adds some debug logs
-v prints out transferred data
rawer is supposed to replace raw,echo=0 according to the documentation
b9600 sets the baud rate
cs8 sets 8 data bits
cstopb=0 sets 1 stop bit
parenb=0 sets parity to none

After 19456 bytes, the output of transferred data on A stops while it continues on B.
If I add wait-slave option to the socat PTY device parameters on A, no transferred data is displayed, neither on A nor B. If I execute cat < /dev/ttySMARTMETER on A, however, transferred data is displayed.

My current conclusion would be that somehow the PTY device /dev/ttySMARTMETER on A isn't successfully opened by ioBroker.smartmeter, however even on silly debug level nothing closely related is displayed.
The last messages before the timeout are

SmartmeterObis options: {"debug":0,"protocol":"SmlProtocol","transport":"SerialResponseTransport","requestInterval":"300","anotherQueryDelay":"1000","transportSerialPort":"/dev/ttySMARTMETER","transportSerialBaudrate":9600,"transportSerialDataBits":8,"transportSerialStopBits":1,"transportSerialParity":"none","transportSerialMessageTimeout":null,"protocolSmlIgnoreInvalidCRC":false}
connected set to false

Ingo Fischer · Answer 3 · Fri May 26 2023 05:34:53 GMT+0800 (China Standard Time)

Pleas epost a full debug log

stephanritscher · Answer 4 · Sat May 27 2023 03:49:18 GMT+0800 (China Standard Time)

2023-05-26 21:37:26.947  - info: host.A "system.adapter.smartmeter.0" enabled
2023-05-26 21:37:26.974  - info: host.A instance system.adapter.smartmeter.0 started with pid 897721
2023-05-26 21:37:27.834  - debug: smartmeter.0 (897721) Redis Objects: Use Redis connection: 127.0.0.1:6379
2023-05-26 21:37:27.864  - debug: smartmeter.0 (897721) Objects client ready ... initialize now
2023-05-26 21:37:27.865  - debug: smartmeter.0 (897721) Objects create System PubSub Client
2023-05-26 21:37:27.866  - debug: smartmeter.0 (897721) Objects create User PubSub Client
2023-05-26 21:37:27.895  - debug: smartmeter.0 (897721) Objects client initialize lua scripts
2023-05-26 21:37:27.899  - debug: smartmeter.0 (897721) Objects connected to redis: 127.0.0.1:6379
2023-05-26 21:37:27.912  - debug: smartmeter.0 (897721) Redis States: Use Redis connection: 127.0.0.1:6379
2023-05-26 21:37:27.916  - debug: smartmeter.0 (897721) States create System PubSub Client
2023-05-26 21:37:27.917  - debug: smartmeter.0 (897721) States create User PubSub Client
2023-05-26 21:37:27.922  - debug: smartmeter.0 (897721) States connected to redis: 127.0.0.1:6379
2023-05-26 21:37:27.936  - debug: smartmeter.0 (897721) Plugin sentry Do not initialize Plugin (enabled=false)
2023-05-26 21:37:27.940  - debug: smartmeter.0 (897721) Plugin sentry destroyed because not initialized correctly
2023-05-26 21:37:27.971  - info: smartmeter.0 (897721) starting. Version 3.3.4 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v18.16.0, js-controller: 4.0.24
2023-05-26 21:37:27.993  - debug: smartmeter.0 (897721) SmartmeterObis options: {"debug":2,"protocol":"SmlProtocol","transport":"SerialResponseTransport","requestInterval":"300","anotherQueryDelay":"1000","transportSerialPort":"/dev/ttySMARTMETER","transportSerialBaudrate":null,"transportSerialMessageTimeout":null,"protocolSmlIgnoreInvalidCRC":false}
2023-05-26 21:37:27.995  - debug: smartmeter.0 (897721) CREATE SERIALPORT: 9600 8 1 none
2023-05-26 21:37:28.000  - debug: smartmeter.0 (897721) SET MESSAGE TIMEOUT TIMER: 120000
2023-05-26 21:37:28.011  - debug: smartmeter.0 (897721) connected set to false
2023-05-26 21:39:28.001  - debug: smartmeter.0 (897721) MESSAGE TIMEOUT TRIGGERED
2023-05-26 21:39:28.003  - debug: smartmeter.0 (897721) Error: No or too long answer from Serial Device after last request.
2023-05-26 21:39:28.005  - warn: smartmeter.0 (897721) No or too long answer from Serial Device after last request.
2023-05-26 21:39:28.005  - debug: smartmeter.0 (897721) Error: No or too long answer from Serial Device after last request.
2023-05-26 21:39:28.006  - debug: smartmeter.0 (897721) Transport Reset!! Restart = true
2023-05-26 21:39:28.007  - debug: smartmeter.0 (897721) SCHEDULE NEXT RUN IN 300s
2023-05-26 21:44:28.010  - debug: smartmeter.0 (897721) CREATE SERIALPORT: 9600 8 1 none
2023-05-26 21:44:28.013  - debug: smartmeter.0 (897721) SET MESSAGE TIMEOUT TIMER: 120000
2023-05-26 21:46:28.014  - debug: smartmeter.0 (897721) MESSAGE TIMEOUT TRIGGERED
2023-05-26 21:46:28.015  - debug: smartmeter.0 (897721) Error: No or too long answer from Serial Device after last request.
2023-05-26 21:46:28.015  - warn: smartmeter.0 (897721) No or too long answer from Serial Device after last request.
2023-05-26 21:46:28.016  - debug: smartmeter.0 (897721) Error: No or too long answer from Serial Device after last request.
2023-05-26 21:46:28.016  - debug: smartmeter.0 (897721) Transport Reset!! Restart = true
2023-05-26 21:46:28.017  - debug: smartmeter.0 (897721) SCHEDULE NEXT RUN IN 300s

Now with log level debug as described in your readme I have more messages than yesterday with log level silly - kind of unexpected. Probably the logic for setting the debug parameter for SmartmeterOrbis doesn't respect the silly level.

Ingo Fischer · Answer 5 · Sat May 27 2023 22:04:50 GMT+0800 (China Standard Time)

Also wie man sieht öffnet der Adapter den seriellen port und bekommt aber keinerlei Daten.

Was sagt denn socat wenn du es im Debug Modus startest?

stephanritscher · Answer 6 · Sun May 28 2023 06:54:46 GMT+0800 (China Standard Time)

socat -d -d -d -d -v -b1 PTY,rawer,link=/dev/ttySMARTMETER,b9600,cs8,cstopb=0,parenb=0,wait-slave tcp:raspberry:4444 2>&1 | tee a.log

a.log

socat -d -d -d -d -v /dev/ttyUSB1,rawer,b9600,cs8,cstopb=0,parenb=0 tcp-listen:4444,reuseaddr 2>&1 | tee b.log

b.log

grep smartmeter /opt/iobroker/logs/iobroker.current.log

2023-05-28 00:44:26.852  - info: host.A stopInstance system.adapter.smartmeter.0 (force=false, process=true)
2023-05-28 00:44:26.854  - info: smartmeter.0 (14302) Got terminate signal TERMINATE_YOURSELF
2023-05-28 00:44:26.853  - info: host.A stopInstance system.adapter.smartmeter.0 send kill signal
2023-05-28 00:44:26.855  - info: smartmeter.0 (14302) terminating
2023-05-28 00:44:26.856  - info: smartmeter.0 (14302) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2023-05-28 00:44:27.381  - info: host.A instance system.adapter.smartmeter.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2023-05-28 00:44:29.901  - info: host.A instance system.adapter.smartmeter.0 started with pid 16547
2023-05-28 00:44:30.780  - debug: smartmeter.0 (16547) Redis Objects: Use Redis connection: 127.0.0.1:6379
2023-05-28 00:44:30.808  - debug: smartmeter.0 (16547) Objects client ready ... initialize now
2023-05-28 00:44:30.809  - debug: smartmeter.0 (16547) Objects create System PubSub Client
2023-05-28 00:44:30.810  - debug: smartmeter.0 (16547) Objects create User PubSub Client
2023-05-28 00:44:30.840  - debug: smartmeter.0 (16547) Objects client initialize lua scripts
2023-05-28 00:44:30.844  - debug: smartmeter.0 (16547) Objects connected to redis: 127.0.0.1:6379
2023-05-28 00:44:30.856  - debug: smartmeter.0 (16547) Redis States: Use Redis connection: 127.0.0.1:6379
2023-05-28 00:44:30.860  - debug: smartmeter.0 (16547) States create System PubSub Client
2023-05-28 00:44:30.861  - debug: smartmeter.0 (16547) States create User PubSub Client
2023-05-28 00:44:30.867  - debug: smartmeter.0 (16547) States connected to redis: 127.0.0.1:6379
2023-05-28 00:44:30.882  - debug: smartmeter.0 (16547) Plugin sentry Do not initialize Plugin (enabled=false)
2023-05-28 00:44:30.886  - debug: smartmeter.0 (16547) Plugin sentry destroyed because not initialized correctly
2023-05-28 00:44:30.925  - info: smartmeter.0 (16547) starting. Version 3.3.4 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v18.16.0, js-controller: 4.0.24
2023-05-28 00:44:30.944  - debug: smartmeter.0 (16547) SmartmeterObis options: {"debug":2,"protocol":"SmlProtocol","transport":"SerialResponseTransport","requestInterval":"300","anotherQueryDelay":"1000","transportSerialPort":"/dev/ttySMARTMETER","transportSerialBaudrate":null,"transportSerialMessageTimeout":null,"protocolSmlIgnoreInvalidCRC":false}
2023-05-28 00:44:30.946  - debug: smartmeter.0 (16547) CREATE SERIALPORT: 9600 8 1 none
2023-05-28 00:44:30.951  - debug: smartmeter.0 (16547) SET MESSAGE TIMEOUT TIMER: 120000
2023-05-28 00:44:30.964  - debug: smartmeter.0 (16547) connected set to false
2023-05-28 00:46:30.952  - debug: smartmeter.0 (16547) MESSAGE TIMEOUT TRIGGERED
2023-05-28 00:46:30.954  - debug: smartmeter.0 (16547) Error: No or too long answer from Serial Device after last request.
2023-05-28 00:46:30.956  - warn: smartmeter.0 (16547) No or too long answer from Serial Device after last request.

Ingo Fischer · Answer 7 · Fri Jun 09 2023 05:41:55 GMT+0800 (China Standard Time)

Honestly ... no idea ... I would have expected to see in socat log when the adapter tries to open the port but there is nothing about that in the logs. also no error sin iobroker ... and when you use cat or such on commandline you get that data?

stale · Answer 8 · Sun Sep 17 2023 08:36:34 GMT+0800 (China Standard Time)

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

stale · Answer 9 · Sun Oct 15 2023 21:44:19 GMT+0800 (China Standard Time)

This issue has been automatically closed because of inactivity. Please open a new issue if still relevant and make sure to include all relevant details, logs and reproduction steps. Thank you for your contributions.
Dieses Problem wurde aufgrund von Inaktivität automatisch geschlossen. Bitte öffnet ein neues Issue, falls dies noch relevant ist und stellt sicher das alle relevanten Details, Logs und Reproduktionsschritte enthalten sind. Vielen Dank für Eure Unterstützung.

stephanritscher · Answer 10 · Sun Oct 29 2023 21:30:10 GMT+0800 (China Standard Time)

Maybe it was a permission issue like #378 - the symptoms were the same and I don't explicitly remember checking the device permissions. Not sure if I will try this solution again. I think running an iobroker slave (see #378) should be more stable with regards to stability than redirecting the device via socat (e.g. if one of the hosts restarts). I was already wondering back then what it would need to detect hung up connections and automatically restart the link and the data collection.