Bridging SignalK server (NMEA) and Home Assistant using signalk-mqtt-bridge and mosquitto (MQTT)

Share your Projects!
21

Hi,

I try to get the writing working to turn the Anchor Alarm on/off.

Here is my switch. And when I use MQTT explorer, I see that the it writes the path as it’s supposed to:

mqtt:
  switch:
    # Anchor Set
    - name: "Anchor Alarm"
      unique_id: "snowdrop_anchor_alarm_state"
      icon: mdi:anchor
      state_topic: "N/signalk/256004128/vessels/self/navigation/anchor/state"
      command_topic: "W/signalk/256004128/vessels/self/navigation/anchor/state"
      value_template: "{{ value_json.value }}"
      payload_on: "on"
      payload_off: "{ value: 'off' }"
      optimistic: false
      device:
        {
          identifiers: ["SignalK"],
          manufacturer: "SignalK",
          model: "HAOS",
          name: "Snowdrop",
        }

It also seems to actually change the value in SignalK, but it immediatley switches back to the old value (in SignalK and HomeAssistant).

One thing I noted is, that the log output from the signalk-mqtt-bridge plugin seams to go into debug mode after the first try. Maybe it’s an issue on the SignalK Plugin side.

Thanks for any help

22

Thanks for the HA Integration, it’s great and if it’s only about getting some data from the N2k bus, it works great.

But SignalK has a lot more to offer and therefore I still want to bridge the two.

One thing I noted when using your Integrtion is, that it get really noisy in the log, when he finds a message on the bus that he can decode and I guess one would have to go and exlude these PGNs manually. Would be great if there was on option to set the log-level and if it’s not on Warning, it would just simply ignore it, if he can’t decode a certain PGN.

23

The yaml files in Home Assistant are very senssitive about syntax. I feel (as opposed to know) that your syntax does not look correct. A check per ChatGPT reveals the following (see below the line). And sorry for using ChatGPT, but with regards to syntax it can be very helpful and has supported me to iron out mistakes from my HA-yamls:

Your configuration.yaml for the MQTT switch in Home Assistant looks mostly correct, but there are a few issues and improvements that can be made. I’ll point them out and suggest a better approach.

Key Issues:

  1. Incorrect payload_off format:

    • The payload_off is currently defined as a JSON-like string, which is not valid for the payload_off setting. It should be a simple string (like "off") unless you intend to send a JSON payload, which requires a command_template (more on that below).
    • payload_off: "{ value: 'off' }" should be "off" (if you intend to send a string).

  2. Use of inline YAML for device:

    • The inline format ({ key: value }) is allowed, but it’s less readable and not the most common practice in YAML. A more standard format would use regular indentation.

  3. Potential issue with value_template:

    • value_template: "{{ value_json.value }}" is fine if your device sends a JSON payload that looks like this:

      { "value": "on" }

      But if you’re not sure about the payload format or it doesn’t return a valid value_json.value, you may need to adjust it.

Recommended Setup

Here’s a revised version of your configuration with some improvements:

Revised Configuration:

mqtt:
  switch:
    - name: "Anchor Alarm"
      unique_id: "snowdrop_anchor_alarm_state"
      icon: mdi:anchor
      state_topic: "N/signalk/256004128/vessels/self/navigation/anchor/state"
      command_topic: "W/signalk/256004128/vessels/self/navigation/anchor/state"
      value_template: "{{ value_json.value }}"
      payload_on: "on"
      payload_off: "off"  # corrected this to a simple string
      optimistic: false
      device:
        identifiers: ["SignalK"]
        manufacturer: "SignalK"
        model: "HAOS"
        name: "Snowdrop"

Explanation of Changes:

  1. payload_off corrected:

    • Changed to "off" instead of "{ value: 'off' }". This will now send the correct payload for turning the switch off.

  2. device section reformatting:

    • Rewritten in standard YAML format (no inline { key: value }). It improves readability and is more consistent with how Home Assistant configurations are usually structured.

  3. Consideration for value_template:

    • Your value_template: "{{ value_json.value }}" seems appropriate if the incoming data is a JSON object containing a value field. If the state returned by the MQTT topic is something like {"value": "on"}, this template should work. Make sure to test and adjust based on the actual message structure.

Additional Recommendations:

  1. Check Payload Structure:
    If your state_topic sends a more complex payload, you might need to adjust the value_template. For example, if the state payload is simply "on" or "off" instead of JSON, you wouldn’t need value_json.value. Instead, just use:

    value_template: "{{ value }}"

  2. Use command_template (if needed):
    If you need to send a JSON payload (for example, { "value": "off" }), you would need to use command_template in combination with payload_on and payload_off:

    command_template: '{"value": "{{ value }}"}'
payload_on: "on"
payload_off: "off"

  3. Debugging:
    If the switch doesn’t behave as expected, use Home Assistant’s MQTT debug features to listen to the topics and verify the payloads being sent/received.

Testing the Setup:

After applying the changes, test the switch in Home Assistant:

  • Ensure the state updates correctly based on the state_topic.
  • Toggle the switch and verify if it sends the correct payload to command_topic.
  • Check Home Assistant logs for any errors related to the MQTT setup.

Let me know if you need more adjustments or run into any issues!

24

Thanks for the input and I’ll put more attention to these details in the future.

However, I tested all variations and observed on MQTT by listening to the topic while triggering all of it and it seems to go out just fine.

The problem is most likely on the other side. I have to investigate the signalk plulgin and specifically how that write mechanism is supposed to work.

25

Which MQTT plugin are you using? I know of six MQTT plugins for SignalK, but the only one that I got to work properly is:
signalk-mqtt-bridge
SignalK Node server plugin that acts as a bridge between SignalK data and MQTT by Iuri Aranda
but this works very reliable and its author Iuri Aranda is also here on the HA forum…

26

I’m using exactly signalk-mqtt-bridge and I’m trying to turn off the Anchor alarm set Hoeckens Anchor Alarm.

I noticed that the Hoeck Anchor Alarm requires the use to be logged in to change the anchor alarm. So I think that might be an issue. Or maybe I’m just sending the wrong payload. Do I need to send a complete Signalk delta? Do you have an example with signalk-mqtt-bridge where you write a value?

I saw the post about the AIS ship tracker. There the OP sent the total amount of tracked ships to SignalK in an Automation. That seems to work.
So maybe the anchor alarm is a special property that needs some extras to send along to change it?

27

Yes, in my local set-up I have a SignalK and a Home Assistant instance and transfer data between both of them. Here is the section from my automations.yaml where I send AIS data from HA to SignalK:

- id: Automation_MQTT
  alias: SignalK data push
  description: Automation MQTT
  trigger:
  - platform: time_pattern
    minutes: /1
  condition: []
  action:
  - service: mqtt.publish
    data:
      topic: R/signalk/d6c7bf05d33a/keepalive
      payload: '["vessels/self/#"]'
  - service: mqtt.publish
    data:
      topic: W/signalk/d6c7bf05d33a/vessels/self/environment/aishub/ships
      payload: '{{ states(''sensor.aishub_ships_in_coverage'') }}'
  - service: mqtt.publish
    data:
      topic: W/signalk/d6c7bf05d33a/vessels/self/environment/aishub/distinct
      payload: '{{ states(''sensor.aishub_unique_ships'') }}'

And here is what arrives in data browser in SignalK:

2025-12-01 16_06_07-
2025-12-01 16_06_07-1244×469 25.7 KB

Sending is done using automations.yaml and receiving is done using configuration.yaml.

28

It looks like my mqtt integration is working. It’s just not impressing the hoeckens anchor alarm very much.

I just tried while the anchor alarm is off and I see the value is written to SignalK as expected with source mqtt:

signalk-set-anchor-on
signalk-set-anchor-on940×662 57.1 KB

But Hoechken Anchor Alarm does not turn on based on that. And, as seen before, it does not turn off either. To turn that on/off by writting a value through MQTT is apparently not the way to go.

29

Okay, I looked at the source code of hoeckens anchor alarm:

The issue is, that is sets the anchor again, whenever it receives a position and there is an anchor position. To Raise the anchor from the HA I would have to not only write anchor-state “off”, but also delete the anchor position and the current radius.

On top, I would need to remember that information before, in case I want to “drop” it again.

I have to think about this a bit more and come up with a new strategy.

30

Well, then three pragmatic ideas here:

  1. Control the effectiveness of the anchor alarm via the radius, i.e. set radius to 20m => anchor alarm active, set radius to 999.999m => anchor alarm inactive;
  2. Control the anchor alarm via propulsion variable, citation: If you have engine data in SignalK (propulsion.*.rpm or propulsion.*.state ) then you can enable the engine check functionality. Then, when you leave the anchorage under engine power, it will automatically end the anchor watch.;
  3. Connect with Zach Hoeken whether a remote on/off switch can be implemented, last change in this repository was 4 months ago, so the repository seems to be alive.

:slight_smile: