thingsboard, hivemq etc. using ESP32 or ESP8266 MQTT. I failed to send data. What am I doing wrong?

[chipfryer27]

It would be good for all flowcode users if the Flowcode team created and released a working example for an mqtt broker

They have, and there are examples of people using the component in the forums such as

viewtopic.php?f=3&t=999&p=5495#p5495

In this example the contributor kindly shared his code based on the WiKi example.

Many more out there....

[ayhan1]

It would be good for all flowcode users if the Flowcode team created and released a working example for an mqtt broker

They have, and there are examples of people using the component in the forums such as

viewtopic.php?f=3&t=999&p=5495#p5495

In this example the contributor kindly shared his code based on the WiKi example.

Many more out there....

Hello again. First of all, thank you for your help. I reviewed all mqtt threads in the forum. But I still couldn't send data via mqtt. I have a few questions below, I would be very happy if you answer them.

My question:
The example of sending data to thingspeak via DS18B20 MQTT is actually the same as the examples on the flowcode wiki page. However, the issue I marked in yellow in the attached picture caught my attention. In the DS1820 example, when publishing, the topic is written as "channels/1234567/publish". However, on the wiki page there is only the topic name (topic: "pot"). Is this a special case of thingspeak? I can't open an account on thingspeak right now and try it, it gives a stupid error. It did not accept normal e-mail (hotmail, gmail, etc.), I opened an account with a corporate e-mail, but I still cannot log in to the account. So I don't have a chance to try this.
I tried all platforms such as Thingsboard, hivemq, emqx and beebotte.

[mnfisher]

Posting should work using the above - 1234567 needs to be replaced by your channel ID number.

I think 'pot' and the like only work using a RPi as MQTT Server...

I couldn't work out how to read a channel using 'subscribe' - hence my example above.

I'll try and post an example this evening showing each step...

Martin

[chipfryer27]

Hi

As far as I am aware, Hive and a few others only accept encrypted connections so many mcu's are out of the question. RPi and ESPs would probably be OK but I am not the best person to ask about TLS on an ESP or such like.

Hive's free service has a web client you can use to test the service, which worked last time I played, but I didn't take it further. I do think though that if you are paying for Hive on your own server you can disable, or rather enable non TLS connections, but don't quote me on that.

A while back I did connect to ThingSpeak, my personal preferred service provider, using MQTT but it was a while ago and I would need to look for my chart. From memory I think it was in relation to a GSM module but testing was done using ESP to establish what needed to be done. I don't recall much difficulty.

You can login to ThingSpeak using yahoo or the like, I do. I posted how to create and use an account etc in the old forum. That was for updating TS using GET etc but once logged in you can do whatever you wish including mqtt.

Actually, to emphasise how easy FC makes this I have modified the WiKi example to update my ThingSpeak. You will need to modify to suit your TS account/channels/fields. In the mqtt component enter your unique details where I have "Your ID" etc. In the component macros enter your unique details (where I have "01234").

This simulates if you enter the correct channel in Network Comms Components for your LAN/WiFi interface. If you don't see an ip address select another channel.

Screenshot 2025-01-19 144009.jpg (57.44 KiB) Viewed 1143 times

RPI3_MQTT_IOT_Publish2ThingSpeak_nodetails.fcfx

(19.37 KiB) Downloaded 8 times

Regards

[ayhan1]

Posting should work using the above - 1234567 needs to be replaced by your channel ID number.

I think 'pot' and the like only work using a RPi as MQTT Server...

I couldn't work out how to read a channel using 'subscribe' - hence my example above.

I'll try and post an example this evening showing each step...

Martin

Thank you very much. I would be very happy if you could make a sample application for a platform like Thingboard.

[mnfisher]

So this is my version for ThingSpeak - it would take some work to change to ThingBoard - and I haven't looked yet...

I've used NetworkComms to do all the work - to give a different perspective from Iain's version.

It writes three data fields to a test ThingSpeak account (.count, count * 2, .count *3 in a loop) - then reads back the last value - splits out the json data and outputs all the fields.

(there seems to be a slight bug in the JSONDecoder - JSONParse - returns 1 less than the number of keys or key values start at 1 ?)

It also outputs the data sent to write the values, the json string - remove some (or all) of the UART:Sends.

There are some largish strings (and the JSONDecoder buffer in properties) - these are 'large enough' at least for this test - but I'd want to test the size of the data sent and returned and adjust them accordingly

WriteChannel - takes up to 3 arguments (if passing "" - then they are ignored - and it should probably test for all three being "") - it would be easy to extend to more - ThingSpeak supports upto 8 (for free?) - but I'd probably use an array here... All values are passed as strings (use ToString$ as here or FloatToString$)

I've added a small amount of error checking - on error it will output a message and stop - other behaviours might be better (retry / retry after a delay / reboot etc)

I feel that there is probably another way to do the send (more like the ReadChannel) - this was the technique I worked out a while ago. I also got the MQTT:Publish towork (thanks to Iain) - but couldn't get subscribe to work - hence the ReadChannel here...

Read channel can read more than 1 'value' back - but might need some increase in buffer sizes if reading bigger data sets

Martin

[mnfisher]

Just re-uploaded (changed the size of the buffer in WriteChannel)

Martin

[chipfryer27]

Hi Martin

The WiKi code I submitted above was modified in a few minutes (all hail FC) just to show that the component and WiKi examples do work and wasn't intended as a solution. I don't think the WiKi examples are either, rather just to illustrate usage.

I don't remember having much trouble using ThingSpeak to read or write using mqtt, but I would need to go hunt down my charts to see how I did it. I've no real appetite for that just now as I am a bit busy.

All I did with ThingsBoard though was to create an account and use their interface to test. As I already had ThingSpeak working I'd no real need for it. I did try unsuccessfully to install TB on a RPi, but being honest I was rapidly losing interest as I laboured through their documentation. I might try the broker install from the WiKi though. It would certainly do all I would ever want, well should I ever implement any iof my ideas

A couple of weeks ago I used the JSON component in the "time machine" post and was initially surprised at how many pairs it returned and where they started, but when I looked at the captured return string (about 1100 bytes if I remember correctly) I did figure it out. Don't ask me to explain now though

Regards

[mnfisher]

All hail.

Many paths lead up the mountain...

There is an interesting 'bug' in my AppendField macro, which doesn't affect the code here, but could catch the unwary. - a small prize and immense pride await...

Martin

[ayhan1]

So this is my version for ThingSpeak - it would take some work to change to ThingBoard - and I haven't looked yet...

I've used NetworkComms to do all the work - to give a different perspective from Iain's version.

It writes three data fields to a test ThingSpeak account (.count, count * 2, .count *3 in a loop) - then reads back the last value - splits out the json data and outputs all the fields.

(there seems to be a slight bug in the JSONDecoder - JSONParse - returns 1 less than the number of keys or key values start at 1 ?)

It also outputs the data sent to write the values, the json string - remove some (or all) of the UART:Sends.

There are some largish strings (and the JSONDecoder buffer in properties) - these are 'large enough' at least for this test - but I'd want to test the size of the data sent and returned and adjust them accordingly

WriteChannel - takes up to 3 arguments (if passing "" - then they are ignored - and it should probably test for all three being "") - it would be easy to extend to more - ThingSpeak supports upto 8 (for free?) - but I'd probably use an array here... All values are passed as strings (use ToString$ as here or FloatToString$)

I've added a small amount of error checking - on error it will output a message and stop - other behaviours might be better (retry / retry after a delay / reboot etc)

I feel that there is probably another way to do the send (more like the ReadChannel) - this was the technique I worked out a while ago. I also got the MQTT:Publish towork (thanks to Iain) - but couldn't get subscribe to work - hence the ReadChannel here...

Read channel can read more than 1 'value' back - but might need some increase in buffer sizes if reading bigger data sets

Martin

Thank you for your help. But I don't understand why this process has to be so complicated.