Hi guys,
I was trying to use mqtt over websockets with Mosquitto and LoRa Server on port 1884. Analyzing the live logs of LoRa App Server, it seems that there are several delays for uplink messages and join.
For example: the device should send each 30 seconds a message, about the temperature, to LoRa Server; when I check the Lora App Server the delay between two uplink messages is about 3 minutes. I need websockets because I want to create a dashboard in order to send commands to the device and display in “real-time” the data about temperature detected by the device. If I use tcp://ip:port for mqtt everything work fine, but I can’t use this with paho mqtt library for javascript, because it is not supported yet.
Has someone already experienced this particular situation?
Regards,
Stefano
You are comparing three things:
- Live frame logs in LoRa App Server
- MQTT over TCP
- MQTT over Webscockets
You say your issue is with MQTT over Websockets, but then you mention that also have an issue with the live output in LoRa App Server (which is not MQTT). Could you clarify what works and what doesn’t work?
tcp://ip:port for mqtt everything work fine
To which topic are you subscribing?
Hi broocar,
the problem is MQTT. I mentioned LoRa app server because from live logs it seems that messages don’t arrive regularly. So i think is a mosquitto server , when using websockets…
Ok 
I’ve never experienced that issue, but I’m also not using MQTT over websockets. Maybe you could also post this on the Mosquitto forum / mailinglist?
I use mqtt for live data, with the paho js client at the UI and mosquitto as the broker. I’ve never experienced any delays and it works just fine, so maybe you are missing some configuration options. I’ll be happy to help you check that.
Hi iegomes,could you tell me how you did?
I explain you our current configuration:
- Client javascript: port 1884 uses MQTT over Websockets. (I’m able to receive temperature data from device);
- Mosquitto: we added the following lines into configuration file ( /etc/mosquitto/conf.d/mosquitto.conf):
listener 1884
protocol websockets
This listener is extra. The default listener of mosquitto is on port 1883. - LoraServer and Lora App Server have the following configuration for MQTT:
server="tcp://localhost:1883"
Before this setting we usedserver="ws://localhost:1884"
With this configuration we are able to see real time data on our javascript client, but we are not able to send commands to device (ex: turn on light). But with a client in Python, using tcp instead of websockets, we are able to send commands to turn on/off light of device.
Thank you,
Stefano
That seems pretty much the same as mine, except I only subscribe from js and never tried to enqueue a message to the device directly from the UI using mqtt over websockets, I just send a request to the API. I’ll try your approach as soon as I get some time and let you know how it goes.
We thought the same solution 
Infact by using mqtt we are not able to send the command, but through API we are able to send the command. If you have any news, let me know!
THank you
Stefano
I’m starting to think that it could be a loraserver problem. May be it does not support mqtt over websockets when you try to send messages from a client javascript. It’s very strange that uplink data can be received using websockets, but not downlink… @brocaar what do you think about this?
Regards,
Stefano
But uplink data isn’t actually received over websockets at loraserver, it’s plain tcp from lora-gateway-bridge to the broker and from the broker to loraserver. Also, how everyone connects doesn’t really matter as it’s the broker’s job to allow subscriptions and publishes using the specified protocols for each client.
So lora-app-server may subscribe to application/[applicationID]/device/[devEUI]/tx using tcp or ssl and publish to application/[applicationID]/device/[devEUI]/rx over the same protocol and you should be able to subscribe and publish to those exact some topics from any other client (as long as its authorized) from whatever other protocol they want. That’s exactly what you do if you subscribe from js to the device data.
I did not understand exactly what you mean. Why if I send an on/off command to device, does the device not receive the data?
Regards,
Stefano
I’m not sure, I haven’t tried it yet, I was just expliciting that in theory it shouldn’t matter which protocols clients choose to connect with.
Hi Iegomez,
I just want to ask you a thing about the POST request /api/devices/{device_queue_item.dev_eui}/queue.
in JSON object, I fill the field data with base64 encrypted value. I put ZmY= as value (the encryption of “ff”). When I check the log of my device I see that the value it receives is completately different (5583). I expected as value ff. Where am I wrong?
Regards,
Stefano
Hi.
I think your encoding is wrong. [0xFF], or just [255], gives me /w== as the base 64 representation. Also, ZmY= gives this when decoding it: [102 102].
Check it here: https://play.golang.org/p/BaI26tAs7pN
I just want to underline a thing about this topic. I’ve tried to use tcp for MQTT and I noticed that the downlink message is confirmed, but when I use mqtt over websockets the downlink message is unconfirmed.When I check in deep the data structure of downlink message (using websockets), the frmPayload is null as shown in the picture below. I really don’t know how to solve this problem.
That looks like a device status request, not a queue message.
Going back to an earlier question, I tried enqueuing a message with the same mqtt client I’m using to get the data and it worked fine. The code is was as simple as this:
let topic = "application/" + this.props.match.params.applicationID + "/device/" + this.props.match.params.devEUI + "/tx";
SessionStore.mqttClient.publish(topic, JSON.stringify(this.state.deviceQueueItem), 0, false);
Are you using mqtt over websocket? I used the same code as in your example.
How did you configure your toml file for mqtt?
Yes, that was trying with websockets from the UI yesterday and it worked fine.
Why would the (¿loraserver? ¿lora-app-server?) toml conf matter for this? You are publishing to the mqtt broker, subscribers don’t care which protocol any other client uses. The UI client will publish over websockets and the subscribers will get the messages over tcp, no client will ever know about the others, only the broker knows and it really doesn’t matter. So I get that you have some bit of a confusion about this and are probably misconfiguring something that’s casuing your issues (¿maybe you are trying to set websockets at the toml as the connection from lora-app-server to the borker or something like that?).
Yes I tried to set websockets in toml…but what i do not understand is the reason why with a python client my lights turn on and off, with javascript no…