We are facing an issue in the customer premises where the gateway which is connected to the meters send data to ThingsBoard using the Node-Red.
To simulate the functionality at the actual client premises created Node-Red nodes which sends data to ThingsBoard. But the data which is received at the ThingsBoard is inconsistent and not at the regular interval which is been set as 30 secs in the Node-Red.
What could be the issue?
Related
Good afternoon, so I have currently an MQTT session active. I am using Eclipse Mosquitto as a broker.
The publisher is a Core2 from M5Stack that has a connected sensor and this device sends the read temperature to Mosquitto which through Prometheus plots the information in software grafana.
So the problem here is that the Core2 sometimes runs out of battery, but grafana keeps plotting data on a loop of the last read value, which is the last value the Core2 sent before disconnecting. We have connected the core2 to the wall but we want to make sure in case it disconnects it will stop plotting data in Grafana.
Any idea on what could I do?
I'm using MQTT paho for android mqtt connection for the last 15 ~ 20 days the client seems to works normally. but from last day the problem occurs.
I can successfully subscribe to messages and able to publish from the client but it won't affect the cloud data.
The subscribe and publish are working normally when I change my clientid to another value.
So my question is that does client id matter in performance issue?
We have an IoT based application device which is configured to communication with our Dashboard via MQTT bridge from Various service providers like Google, AWS and Azure.
So the flow is:
Device start TLS session with service provider.
Subscribe to a particular topic and wait for messages from the
service provider with 5 second timeout.
Dashboard publishes messages to same topic periodically.
IoT service provider broadcast it to all devices subscribed.
Publish and subscribe messages are with MQTT QOS 1 services.
Observation:
AWS and Azure works fine with above flow, but device stop receiving messages from Google MQTT bridge after 3-5 successful iterations even though our dashboard is publishing messages to Google IoT MQTT bridge.
For Google, we have identified that control flow is different when compared with Azure and AWS.
For Google, we need to subscribe and un-subscribe for a given topic every-time before waiting to receive message while for AWS and Azure we need to subscribe once during opening a MQTT connection.
Issue:
Sometime 5 sec device timeout occurs as it could not receive messages for subscribed topic from Google MQTT bridge. Adding multiple retries to overcome timeout issue was unsuccessful as issue still persist as device could not receive message from Google MQTT bridge after 45-60sec of device operation after powering on.
Is there is constraint with Google MQTT bridge to receive messages periodically without subscribing it every-time?
How can device receive messages without timing out (5 sec) from Google MQTT bridge?
Is there any workaround to recover a device once it got timed out with establishing MQTT reconnection?
I am using google iot core as well,the device side code for the mqtt client is golang while using paho mqtt package. this client package support OnConnect handler which while using this handler I achieve the recovery which I think you are looking for.
Via this handler I am re-subscribing to the "config" topic.
I think that google does not save the subscriptions which the clients are subscribed to and therefore the client needs to re-subscribe upon successful connection
Here's the golang code I've used (inspired by gingi007's answer, thank you!)
var onConn MQTT.OnConnectHandler
onConn = func(client MQTT.Client) {
fmt.Println("connected")
client.Subscribe(topic.Config, 1, handlerFunc)
}
mqttOpts.SetOnConnectHandler(onConn)
client := MQTT.NewClient(mqttOpts)
this way config updates keep flowing to my device, while if you subscribe outside of the onConnectHandler you'll just receive one config update when you connect.
I am using Google IOT core with mongoose os. I wanted to update device connection status to firestore. But i am unable to find event which reports mqtt connection status to pub/sub like when device disconnects or reconnect i.e if device is offline or not.
I am stuck on this problem for days.Any help will be appreciated
Update
As #devunwired mentioned in this response it is now possible to monitor Stackdriver logs for disconnect events. You must have at a minimum enabled INFO level logging on your project in IoT Core > Registries > [your registry] > Edit Registry > Select "Info" log level > Click save.
Original Response
There are a few values you can look at that are tracked in device configuration metadata that you could use to know when a device last was online:
Last Configuration Send time - sent anytime your device connects /
configuration is posted
Last Event Time - Last time an event was sent from the device
Last State Time - Last time state was sent from the device
Last Heartbeat time - Last time MQTT heartbeat was sent
To get you started, here is an example using API explorer that you can fill-in with your project ID, region, registry, and device to query for a specific device's metadata.
For 1...3 you have control over these through device manager and by publishing data. MQTT heartbeat is updated if your device sends an MQTT_PINGREQ message during the "ping period" without other messages getting sent.
At any rate, you could use any of these update time values to see the last time a device was online / functioning. You could query the states of your devices after listing the devices in a registry and could update a Firebase RTDB periodically if that's how you want to report (e.g. using AppEngine TaskQueue). Note that you also just can get these "last connected" values from the Google Cloud Console.
It was said before but we don't have an event for disconnect, just configuration ack, which generally is the connection event. If you want to share state between a device and the device manager, use state messages.
Unfortunately, there's no built in way to do this right now as there aren't events on this state.
However, you could implement a hack by sending a message on connect/disconnect from the device that you have a Cloud Function subscribed to the Pub/Sub topic listening for. It's not perfect as it would fail in the case where the device disconnected unexpectedly.
There currently is no way to do this, that i've been able to find (a year later after this original post). I posted a question here on SO regarding this as well, with more details and link to example code I had to use for handling this:
Google Core IoT Device Offline Event or Connection Status
The AWS IoT platform publishes messages on a special MQTT topic (prefixed with $aws) when your device connects/disconnects. You can easily use these to monitor these events - however, you should be aware that the MQTT protocol is designed to be robust to a poor networking conditions and the broker on the AWS side probably doesn't think it's a bit deal to disconnect a client. The broker expects that the client will just reconnect and queue messages for a moment during that process (which can be a big deal on a microcontroller).
All that being said, the AWS topics you would watch are:
$aws/events/presence/connected/{clientId}
and
$aws/events/presence/disconnected/{clientId}
and the documentation for these (and other) lifecycle events are located: https://docs.aws.amazon.com/iot/latest/developerguide/life-cycle-events.html
I am using Raspberry Pi as Thingsboard gateway and pushing sensor readings to server successfully. The Server may not be always online. Where does the data goes in case of server goes offline for long duration? Is there any storage in the Thingsboard gateway?
The "Thingsboard gateway" doesn't have database like Thingsboard Server application but it stores the MQTT messages in case of disconnection from the remote server.
As mentioned the Thingsboard gateway is on Raspberry Pi so go to following directory and make the changes:-
sudo nano /etc/tb-gateway/conf/tb-gateway.yml
there you will find the "gateway.connection.maxInFlight" which represents maximum amount of pending publish messages. Pending messages are messages that are either not sent due to connection problem or not yet confirmed due to high load on Thingsboard Server. Its default value is 1000 (messages). In case of per minute publish cycle ~16 hours of disconnection will be handled by the system.
The persistence settings are configured in the /etc/tb-gateway/conf/tb-gateway.yml file. You can have either “file” or “memory” message persistence. In the latter case data is only memorized in dynamic memory of tb-gateway service, so the following considerations apply only for the "file" option.
The path where data will be stored in case of connection issues between the gateway and the server is also specified in tb-gateway.yml. Default location in Raspbain is: /usr/share/tb-gateway/bin/storage/