serial, Ethernet to MQTT
I have developed a new MQTT bridge to convert from serial, ethernet to MQTT.
Supports for MySensors.
You can have more than one serial ports and/or ethernet connections.
If you are interested in, https://github.com/mycontroller-org/2mqtt
I was testing if I could use the old workflow that we used in our weather station school project, using an Arduino with RFM69 radio as a serial gateway broadcasting messages to local Mosquitto MQTT broker from where MyController then picks up the messages.
I noticed that compared to your new v2 MyController's internal serial gateway, your 2mqtt bridge consumes more CPU cycles.
Compare that when your builtin serial gateway is enabled from within MyController v2 UI with low CPU usage:
to your standalone 2mqtt bridge with higher CPU usage:
And I double checked that the builtin serial gateway was disabled from within the MyController v2 UI. I even tried to terminate MyController and checked with MQTT.fx if data was incoming from the bridge and I can confirm that I was still receiving valid data besides the high CPU usage.
Is this normal, or should I file a issue on your GitHub repository?
Hi, @j54n1n Thanks for the detailed report.
It does not look normal. It can be a bug in 2mqtt
Can you share your configuration details used in 2mqtt? (remove sensitive details)
@jkandasa yes sure, I was not using any special configuration. I adapted the config file only to suit the configuration that we used before.
Here we go for the config.yaml file:
logger: mode: development encoding: console level: info adapters: - name: adapter1 enabled: true reconnect_delay: 20s provider: mysensors_v2 source: type: serial port: /dev/serial0 baud_rate: 115200 transmit_pre_delay: 10ms mqtt: broker: tcp://127.0.0.1:1883 insecure_skip_verify: false username: password: subscribe: mysensors-in/# publish: mysensors-out qos: 0 transmit_pre_delay: 0s reconnect_delay: 5s - name: adapter2 enabled: false reconnect_delay: 20s provider: mysensors_v2 source: type: ethernet server: tcp://192.168.10.21:5003 transmit_pre_delay: 10ms mqtt: broker: tcp://192.168.10.21:1883 insecure_skip_verify: false username: password: subscribe: in_nrf24/# publish: out_nrf24 qos: 0 transmit_pre_delay: 0s reconnect_delay: 5s - name: adapter3 enabled: false reconnect_delay: 20s provider: raw source: type: serial port: /dev/ttyUSB0 baud_rate: 115200 transmit_pre_delay: 10ms message_splitter: 10 mqtt: broker: tcp://192.168.10.21:1883 insecure_skip_verify: false username: password: subscribe: in/my_topic publish: out/my_topic qos: 0 transmit_pre_delay: 0s reconnect_delay: 5s
and for my environment on the Raspberry Pi:
$ cat /etc/*release PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs" $ uname -a Linux metteo-dev2 5.10.17-v7+ #1421 SMP Thu May 27 13:59:01 BST 2021 armv7l GNU/Linux $ ls -l /dev/serial0 lrwxrwxrwx 1 root root 7 Jul 14 20:00 /dev/serial0 -> ttyAMA0 $ ls -l /dev/ttyAMA0 crw-rw---- 1 root dialout 204, 64 Jul 14 20:00 /dev/ttyAMA0 $ groups pi pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio lpadmin $ apt-cache policy mosquitto mosquitto: Installed: 1.5.7-1+deb10u1 Candidate: 1.5.7-1+deb10u1 Version table: *** 1.5.7-1+deb10u1 500 500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages 100 /var/lib/dpkg/status
Thanks in advance
@j54n1n Thanks for the detailed configuration. I try to create this setup in my environment.
@j54n1n I can reproduce this issue. kindly file a bug. I will work on it. Thanks!
@jkandasa thanks, ok here is the link to the issue: https://github.com/mycontroller-org/2mqtt/issues/1
@j54n1n I have fixed the issue, can you please verify it in the master build?
@jkandasa thanks, yes now I get low CPU usage.
Nice work ^^
I believe I my change will not impact the functionality
Please let me know if you see a different behavior in the recent build
@jkandasa Ok, I quickly looked through it with MQTT.fx and it seems to be fine.
Thanks again. Now I will start looking for strange behaviors with MySensors in your MyController v2.
@j54n1n thanks again! please report back if you find any