Please explain what mechanism chirpstack is using to queue message prior to publishing to MQTT. I am using HA Core because HA OS does not support RPi5. With HA Core no addons are possible. I am able to integrate MQTT but it appears from message below that the topic is queued and the gateway then publishes to MQTT. It appears that I cannot publish directly from HA to MQTT to the node?
You need to strictly follow the LoRaWAN Architecture.
External Systems <=> LoRaWAN server <=> LoRaWAN gateway <=> LoRaWAN nodes.
But how do I proceed? (Please add some value here as I am stuck)
My HA is updating with the trigger event but neither of the action topics (below – automation.yaml for Home Assistant)
register on the chirpstack server log as I have tried both. The second topic below is the one that is internally triggered after I use chirpstack queueing so I gave it a try. The first one is ChatGPTs recommendation. I updated chirpstack.toml with a
downlink = in each case to try them out but to no avail. Of course the MQTT server sees them.
If I use queueing in Chirpstack the server log shows the event and the firmware on the node receives message
Chirpstack.toml excerpt:
Thanks
Is your issue here just that you cannot trigger a downlink using MQTT?
If so look at the example payload here: MQTT - ChirpStack open-source LoRaWAN® Network Server documentation
Your first payload is missing a devEUI and the second is missing a data field. Remove your downlink topic in the [integration.mqtt] section as well.
@Liam_Philipp …my issue is that Chirpstack queuing generates messages that are then sent on to the node and understood. This queueing can be seen when monitoring the chirpstack server via docker logs.
I would like home assistant to be able to do this (ie send messages to the node).
I changed my chirpstack.toml (see above …I blacked out device # and application #) and I changed my automation.toml for home assistant to the above (also blacked out dev_eui and application number as it didn’t seem appropriate to share the numbers). My home assistant toml is showing that 4 seconds after I receive the incoming trigger (which I do ) to trigger a downlink…I never see anything of the event showing up on the logs…The log file excerpt I show above is wrt chirpstack queuing. You can also see from chirpstack.toml two downlinks I have tried but neither trigger the chirpstack log…I believe somehow chirpstack when queued internally is creating the first log message (see above) and then the server is creating (internally) the event/txack message. I don’t know how to get past this? (Hopefully this makes sense)
@Liam_Philipp
See changes you requested below:
Chirpstack.toml
Automation.yaml
Per your link it looks like command/down is not an eventType and can be removed/should be removed.
Some of those changes you suggested came from a repo as I was trying to figure it out. I don’t understand getting rid of the downlink topic however in chirpstack.toml…When you queue a message with chirpstack it clearly shows a publishing event to mqtt. My interpretation here was that the application server was publishing this event and that the network server side of chirpstack was most likely subscribing to the same published downlink topic and then handing it off to the gateway to get pushed to the node?
I hadn’t realized you were using Home Assistant when I told you to remove the downlink_topic from [integration.mqtt] (idk if Home Assistant uses it) but I am not sure what it is used for. Looking at the configuration defaults/options: Configuration - ChirpStack open-source LoRaWAN® Network Server documentation downlink_topic isn’t even a variable Chirpstack uses. Regardless I don’t understand changing any topics as the default values for topics should suffice? Maybe explain your rationale for adding the line.
From the link:
"The default topic for scheduling downlink payloads is: application/APPLICATION_ID/device/DEV_EUI/command/down "
command/down is not an “event type” I suppose but is the default topic that your home assistant should push the MQTT messages to in order for Chirpstack to receive them, from there Chirpstack posts the command to the region_prefix/gateway/… topic your gateway bridge subscribes to in order to send the downlink to it.
I am not used to Automation files like the .yaml you provided but it looks like the payload and topic for your command/down look fine. Although you should not be posting to txack, as that is for the devices/gateways response to a downlink.
Are you sure your mqtt.publish even works? Is it posting events to the MQTT broker? Subscribe to the topic and see.
@Liam_Philipp …
I removed the txack within automation.yaml.
If I publish from home assistant using the integrated MQTT broker to the topic and I subscribe to that topic then yes my MQTT shows the results (see below I published two packets
application/<id #>/device/<id #>/command/down
mosquitto_sub -h localhost -t application/<id #>/device/<id #>/command/down
"hello world"
"dev_eui":<id #>, "confirmed":false, "fPort": 43, "data": "BBQk"
It is likely just an issue with the formatting of the payload.
The obvious issue is if you look at the example payload
{
"devEui": "0102030405060708", // this must match the DEV_EUI of the MQTT topic
"confirmed": true, // whether the payload must be sent as confirmed data down or not
"fPort": 10, // FPort to use (must be > 0)
"data": "...." // base64 encoded data (plaintext, will be encrypted by ChirpStack)
"object": { // decoded object (when application coded has been configured)
"temperatureSensor": {"1": 25}, // when providing the 'object', you can omit 'data'
"humiditySensor": {"1": 32}
}
}
its devEui not dev_eui. The other thing (I could be wrong here) is I would expect there to be curly braces around the payload. When you subscribe I believe you should see:
{"devEui":<id #>, "confirmed":false, "fPort": 43, "data": "BBQk"}
not
"devEui":<id #>, "confirmed":false, "fPort": 43, "data": "BBQk"
Perhaps the formatting of the string excludes the curly braces there.
@Liam_Philipp
I tend to agree on packet issue…If I correct the devEui and then use the MQTT broker in home assistant to publish I now get a warning when monitoring the device logs for chirpstack
Processing command error: invalid type: string "devEui", expected struct integration.DownlinkCommand at line 1 column 8 topic
What do I do with respect to my packet (see above) to solve this? (more { …})?
Simply throwing more {} will not solve the problem…
You need to find what is wrong with your formatting and why the {} are being exempt, sometimes you need an alternate character before the { and } for them to be treated as the actual character and not a string formatting operator. Google or ask GPT.
@Liam_Philipp …I will investigate this evening.
Thank you for your support! It has been very helpful
@Liam_Philipp …
Quick follow up…I needed to add the {} as a wrapper to the payload packet to let the service know it was a JSON packet. After this and a few tweaks in the automation.yaml and configuration.yaml I was able to add a button that now sends down data to the node.
Thank you for your help in solving this matter!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.