@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

@jkandasa Hello, I would also like to try out your new version. At our school we have been using your old v1 Java implementation for our weather station build by our students. It is running on a Raspberry Pi connected to the serial pins via radio receiving data from a custom made MySensors node.

You can find our old setup code here: https://gitlab.com/rrbz/meteo/metteo/-/blob/0241002c06f0258949590810258b72c2a95ff543/metteo-config.lib.sh#L380-492

Basically we setup everything by overwriting the initial configuration by a preconfigured MyController settings backup and do a little housekeeping with systemd unit files.

@jkandasa thanks, ok here is the link to the issue: https://github.com/mycontroller-org/2mqtt/issues/1

Cheers j54n1n

@jkandasa yes it was at startup, but only once so far and after a restart of the service I did not see that again. Maybe some type of race condition? Could it be that it depends if either influxdb or mosquitto are ready or not at boot?

This is the service unit file that I am using:

[Unit]
Description=MyController.org v2 daemon
Requires=network.target
After=influxdb.service

[Service]
User=mycontroller
Group=mycontroller
WorkingDirectory=/opt/apps/mycontroller
ExecStart=/opt/apps/mycontroller/mycontroller-server -config /opt/apps/mycontroller/mycontroller.yaml

[Install]
WantedBy=multi-user.target

@jkandasa thanks, yes now I get low CPU usage.

Nice work ^^

@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.

@jkandasa yes it was at startup, but only once so far and after a restart of the service I did not see that again. Maybe some type of race condition? Could it be that it depends if either influxdb or mosquitto are ready or not at boot?

This is the service unit file that I am using:

[Unit]
Description=MyController.org v2 daemon
Requires=network.target
After=influxdb.service

[Service]
User=mycontroller
Group=mycontroller
WorkingDirectory=/opt/apps/mycontroller
ExecStart=/opt/apps/mycontroller/mycontroller-server -config /opt/apps/mycontroller/mycontroller.yaml

[Install]
WantedBy=multi-user.target

Hello @jkandasa
Today in the morning at startup of my Raspberry Pi I got a crash about concurrent map read/write in one of the goroutines. See also the file dump from my systemd service.

Is it something serious to post it as an issue on Github?

@jkandasa ok, thanks for your info on that topic.

So maybe could there be in the future a more official way to script this? You mentioned for example in the Github issue from MyController v2 some form of scripting.

Or maybe going back to the v1 approach of a backup file or something like that?

Kind regards

Hello @jkandasa,
Now I am trying to automatize the installation of MyController v2 from within a Bash script, where I want to preset the MySensors gateway.

I found your documentation at https://v2.mycontroller.org/docs/user-interface/resources/gateway-mysensors/ where you show also as an example a yaml file. Furthermore I found within the directory mc_home/data/storage/memory_db/yaml/ a file called gateway__1.yaml with the settings of the gateway that I inserted via the web UI.

The content of the file is like the following:

- id: MySensors
  description: MySensors Serial 2MQTT Bridge
  enabled: true
  reconnectdelay: 30s
  queuefailedmessage: false
  provider:
    enableInternalMessageAck: true
    protocol:
      broker: tcp://127.0.0.1:1883
      publish: mysensors-in
      qos: 0
      subscribe: mysensors-out/#
      transmitPreDelay: 10ms
      type: mqtt
    retryCount: 3
    timeout: 500ms
    type: mysensors_v2
  messagelogger:
    type: none
  labels:
    location: server
  others: {}
  state:
    status: up
    message: Started successfully
    since: 2021-08-06T17:40:06.560894835+02:00
  modifiedon: 0001-01-01T00:00:00Z
  lasttransaction: 0001-01-01T00:00:00Z

Can I simply assume that if I drop such a yaml file in that folder that a new installation of MyController v2 will simply pick it up or do I need to setup also something else?

Also most likely in the preconfigured yaml file I can simply drop the part of state:, modifiedon: and lasttransaction:, right?

Also can be the name of the file anything or do I need to follow some convention?

Thanks

Hello @jkandasa,

In the meantime I did some test runs with the weather station and I did notice some things.

1. The forecast field is missing its text value and it is showing always 0 instead, like so:
   
   I think it is related to how you map the MySensors field data types. Here at plugin/gateway/provider/mysensors_v2/constant.go you map it as a float type, but according to the MySensors Protocol 2.x documentation it should be a string of either "stable", "sunny", "cloudy", "unstable", "thunderstorm" or "unknown". Your old v1 controller seems to intercept that correctly and shows for example the sun or the cloud symbol. Do you intent that to do the same also in your new v2?

2. Regarding the data types it seems when the type none is mapped a string can be displayed for a field. For example this is the case for your old v1 style RSSI indicator message:
   
   So maybe the first point can be partly resolved by changing the type. Furthermore do you intent also reuse your old style RSSI message to let it show at the node status page? Or do you want to support either the MySensors I_SIGNAL_REPORT_REQUEST feature or the NodeManagers signal sensor to show its value at the node status page? In my case the later solution would fit the best because our node is sleeping most of the time without smart sleep to conserve power.

3. Currently the internal message for the battery percentage is not showing up anywhere. Also there your old v1 controller would show the percentage on the node status page. The MySensors implementation is similar as the NodeManagers SensorSignal solution but it is using an internal message type.

So I think that was everything for now. I am curious what you are thinking about it.
Thanks in advance and kind regards.

@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.

@jkandasa thanks, yes now I get low CPU usage.

Nice work ^^

@jkandasa thanks, ok here is the link to the issue: https://github.com/mycontroller-org/2mqtt/issues/1

Cheers j54n1n

@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

Hello @jkandasa,

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.

I was using your suggested settings as mentioned in your documentation MySensors | MyController.org and from your readme file on 2mqtt/README.md.

Is this normal, or should I file a issue on your GitHub repository?

Kind regards