add TCP support for nanoCUL

[kubax]

Hi,

first of all, this is pretty much untested (i confirmed the connections with netcat, but do not have the nanoCUL or tcp232 adapter yet).

This should add a "CULTCP" adapter to the selection, and using "tcp://ip:port" in the custom device field.

please be aware of horible coding, as this is my first ever addition to a node plugin, or node at all.

CulTCPReceiver.js is basicly copied from the serial version, with some minor tweaks. The real "fun" is in TCPDevice.js and is mostly borrowed from other projects and modified to fit this project.

right now the TCP connection is dropped when the CUL is not verified, and never tries to reconnect. This should be replaced by a reconnection after some minutes, but i have no idea how one would do that.

hopefully it is clear what i am trying to archive.

[kubax]

Just wanted to add, that i did successfuly test it today.

It connects to the TCP Port of my USR-TCP232-T2 and Sends the commands for version detection + mode selection.

I (for now) just can't get any water meters or anything else listed in the devices, but that could be because (maybe) no one in my range allready has a water meter with wmbus.

My local water company will install the reader this next thursday. Then i might be able to report the device detection. (not dectiption as i have to get the key first from my water company)

[lvogt]

Hi,

thanks for your contribution. Awesome that your implementation seems to be working. However, this will introduce quite a bit of duplicated code. I will try to refactor your approach as TCPDevice is more or less a direct copy of SerialDevice.

A debug log when the adapter starts and initializes the CUL would be helpful.

[kubax]

sure, here is the log.

2023-04-15 15:46:12.273 - info: wireless-mbus.0 (229363) starting. Version 0.8.10 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v18.15.0, js-controller: 4.0.24
--
2023-04-15 15:46:12.302 - debug: wireless-mbus.0 (229363) Created device of type: CULTCP
2023-04-15 15:46:12.303 - debug: wireless-mbus.0 (229363) CUL: TX: 560d0a
2023-04-15 15:46:12.310 - info: wireless-mbus.0 (229363) CUL: Connected to 192.168.178.26:20108
2023-04-15 15:46:12.327 - debug: wireless-mbus.0 (229363) CUL: RX: 5620312e3637206e616e6f43554c3836385f723536380d0a
2023-04-15 15:46:12.328 - info: wireless-mbus.0 (229363) CUL: Version: V 1.67 nanoCUL868_r568
2023-04-15 15:46:12.328 - debug: wireless-mbus.0 (229363) CUL: TX: 5832310d0a6272730d0a
2023-04-15 15:46:12.328 - silly: wireless-mbus.0 (229363) States system redis pmessage system.adapter.wireless-mbus.0.logLevel/system.adapter.wireless-mbus.0.logLevel:{"val":"silly","ack":true,"ts":1681566372287,"q":0,"from":"system.adapter.wireless-mbus.0","lc":1681313724668}
2023-04-15 15:46:12.329 - debug: wireless-mbus.0 (229363) connected set to false
2023-04-15 15:46:12.340 - debug: wireless-mbus.0 (229363) CUL: RX: 534d4f44450d0a
2023-04-15 15:46:12.340 - info: wireless-mbus.0 (229363) CUL: Receiver set to S-MODE and data reporting with RSSI
2023-04-15 15:46:12.386 - debug: wireless-mbus.0 (229363) connected set to true

curently the connection drops (most likely because of the USR-TCP232-T2 resetting the connection after some time of no data, regardless of keepalive) after around 3 hours. as a quick workaround i replaced the onError call with another function that tries to reconnect after around 30 seconds (at least i'm trying to do so right now)

[lvogt]

The current master should support tcp://host:port as "custom serial port". Please give it a test when you have time (and especially when your meter arrives).

I am not sure whether I should update the admin page to make this feature more prominent...

[kubax]

first of all, thanks for implementing it!!

i did test the current master, and it seems like it is working as intended.

here is a log output from connecting:

2023-04-17 23:29:05.891 - info: wireless-mbus.0 (113637) starting. Version 0.8.10 in /opt/iobroker/node_modules/iobroker.wireless-mbus, node: v18.16.0, js-controller: 4.0.24
--
2023-04-17 23:29:05.918 - silly: wireless-mbus.0 (113637) States system redis pmessage system.adapter.wireless-mbus.0.logLevel/system.adapter.wireless-mbus.0.logLevel:{"val":"silly","ack":true,"ts":1681766945910,"q":0,"from":"system.adapter.wireless-mbus.0","lc":1681313724668}
2023-04-17 23:29:05.940 - debug: wireless-mbus.0 (113637) Created device of type: CUL
2023-04-17 23:29:05.942 - debug: wireless-mbus.0 (113637) CUL: TX: 560d0a
2023-04-17 23:29:05.954 - debug: wireless-mbus.0 (113637) CUL: RX: 5620312e3637206e616e6f43554c3836385f723536380d0a
2023-04-17 23:29:05.954 - info: wireless-mbus.0 (113637) CUL: Version: V 1.67 nanoCUL868_r568
2023-04-17 23:29:05.955 - debug: wireless-mbus.0 (113637) CUL: TX: 5832310d0a6272630d0a
2023-04-17 23:29:05.967 - debug: wireless-mbus.0 (113637) CUL: RX: 434d4f44450d0a
2023-04-17 23:29:05.967 - info: wireless-mbus.0 (113637) CUL: Receiver set to C-MODE and data reporting with RSSI
2023-04-17 23:29:05.969 - debug: wireless-mbus.0 (113637) connected set to true
2023-04-17 23:29:06.013 - debug: wireless-mbus.0 (113637) connected set to true

I will report back on Thursday with a log that hopefully shows my new water meter.

EDIT: I know i will get a Kamstrup Multical 21, do you know what mode it should be? If i recall correctly from one forum entry it is C Mode, right?

[kubax]

Today my water meter was installed, but i can't seem to get any telegrams from the receiver. i got one when i desoldered the TCP232 and used it with the normal usb adapter included. but with an rssi of -89 so pretty weak.

i ordered a (hopefully) better antenna, and am curently laying tripwires around my house trying to get a telegram from my meter one room under and one room left ( so diagonally to the receiver) with no luck so far.

I'm note quiet sure if the tcp232 powered via connecting the 3.3v line and gnd from the nanocul draws to much power, so the nanocul can't handle the signals anymore, because it doesn't get enough power.

tomorrow i will also try to add another usb connection to power the tcp232 withouth piggybacking the power from the nanocul...

[kubax]

Sorry for the long time to respone back.

I now did get it to work, but in a litle different way then expected.

First of the changes you made seem like to work perfectly fine. Only thing that seems a little bit wonky is if the connection via TCP is lost somehow. i do not have any long term tests (yet) but if the connection is lost, it seems like the adapter stalls up until manuel restart.

MAYBE send a "V" (in case of CUL) from time to time and see what the reaction is could fix this.

I had to change the USR-TCP232-T2 with a NodeMCU (ESP8266) because the intended place was ontop of my closet in the living room, did not get enough signal to get any data.

The place where i did get data sadly has no lad port anywhere near enough, so i switched to a NodeMCU wich i had laying around.

EDIT: i forgot to mention, it seems like the Kamstrup Multical21 is decoding a litle bit wrong. I do get "VIF_FLOW_TEMP" of 127 wich should be very wrong, or i dont undersand the value right xD

Value KAM-75****85.data.5-1-VIF_EXTERNAL_TEMP: 5
Value KAM-75****85.data.4-1-VIF_FLOW_TEMP: 127
Value KAM-75****85.data.3-1-VIF_VOLUME: 0
Value KAM-75****85.data.2-0-VIF_VOLUME: 3.733
Value KAM-75****85.data.1-0-VIF_KAMSTRUP_INFO_20: 0
Updating device: KAM-75****85

[kubax]

i just added (very) simple reconnection of the TCP Devices

[lvogt]

About the wrong temperature: I expect that decoding is fine and the meter sends this nonsense value (for whatever reason). But I can only verify that if you post a raw message from the debug log.

About the reconnect: I expected that I need to adjust that. I do not know if you say / used that, but the main branch already as reconnect in the "main.js" level implemented, but only if an "device error" occurs. If that did not already help your connection, I will happily implement a reconnect "onDisconnect".

You also bound the same method for onClose. I do not really like that. It makes it impossible to cleanly close the tcp connection. Can you verify if that is really necessary?

You also suggested somewhere sending "V" as a keep alive message. Is this just a guess or do you know that this will make the connection more robust?

[kubax]

i think you were right and the sensor just calibrated it self? Because now i get more sane temperatures. :shrug: Maybe the reading is just wrong of the flow temperature was under 0°c ? because now it's telling me that it's 7°c

As of the disconnect issues. It might have been a problem other than the plugin. i used ESPHome to made the nanoCUL available via TCP port. But it seems like the seriaServer addon for ESPHome is a litle bit unstable.

I recently tested ESPEasy and it's serialServer, and that did not get any connection losses (other than trying to connect form another machine to inspect the traffic, wich leads to closing the original connection). Shortly i do get some real ESP8266 Boards (the NodeMCU is was using had a ESP32 inside, wich i didn't know at the time) and i will try with ESPLink wich should support multiple connections to the same serial over TCP.

I did include the reconnect on closing, because of this behaviour. i didn't think about the part that this would also be called when the plugin tries to stop the connection, but you are right... that would be a problem closing the connection cleanly.

The suggestion for sending "V" as a form of keep alive is just a guess, but would be a way of testing if the connection is still alive and the nanoCUL is answering. For now my connections did not get dropped in the last at least 24h, i guess.

[lvogt]

Hi, I update the master branch. Please test it, if you have time. Even though I already updated all "version numbers" in the code, this is still not tagged, nor uploaded to npm.

I would hold off from implementing the "version keep alive" for now. If you still keep "too many" connection drops, I will look into this.

[kubax]

sorry for closing and reopening the PR multiple times. Every time i sync your changes to my fork, the PR gets closed automatically.

I tried your changes, and disconnect doesn't seem to be enough.

i checked with ss from withing the container, and i still see the connection as established way past me rebooting the wireless adapter or connection from another machine (that actually was not true... after connection from another client, the connection is dropped by the system, but the plugin does not try to reconnect... most likely because it is closed by the server).

should we change this to a issue, because i can't open this up again, as i don't have any changes to reopen the PR :)

[kubax]

one possible way for the problem when the connection is unexpectedly dropped, could be setting a timeout for the connection.

147             this.port.setTimeout(1000 * 60 * 5);
148             this.port.on('timeout', this.onError);   

this workd, but only because the plugin crashes (looks like onError tries reading a message, that is not send on the timeout event) so a new function might help that tries to reconnect on a timeout.

[lvogt]

Hi sorry for the late reply,

Could you test the code from the tcp-reconnect branch? I rolled back the "higher level" reconnect and more or less took your first suggestion, but with (hopefully) an addition to make the connection terminate gracefully if wanted.

Also your first suggestion contained the "disconnect" event - I do not find any documentation of it. Where did you get it?

[lvogt]

Did you have time to give the tcp-reconnect branch a try?

[kubax]

Sorry, i totaly forgot to test the branch.

I replaced it a few minutes ago with your testing branch, and it looks good.

reconnecting works with a forced disconnect through connecting with another client to the port.

[lvogt]

Thanks for the test. This has been published as 0.9.0 now.