Flowcode Support Board

Hi,
This is not an FC issue and probably my fault (rather than strange) but I am struggling to find out what the problem is.
I have a program that is working well so far, I changed the NumDP in AssignDataAsFloat to get 3 decimal places and this worked as expected for the first value. I then tried to do it for the other 3 values (or just one of them) and it basically seems to lock up the web app where nothing changes. I can see the data being sent (or at least the string prior to sending) but the web app just stops working.
I tried extending the string as I thought it might be an issue but that caused other more severe issues.

Is there a simple way I can see the MQTT data without using the web app so I can see what is actually being sent.

I know it is not and FC issue but if anyone is interested I will see if I can make a demo to show the problem.

Regards,
Bob

Hi,
After a lot of trial and error (lots of errors) I have resolved it, I shortened all the topic names. I am not sure why that worked and lengthening the data string didn't.
Anyway, as a bonus it also seems to have resolved an issue where the ESP32 was restarting every 4 minutes.

I have just ordered this tee shirt, I think I deserve it. Bob

Hi Bob

If you are using MQTT 3.1 you might be running into problems if you exceed maximum allowable lengths. Client ID for example used to be restricted to 23 characters.

Just a guess.

Regards

Hi Iain,
I think it is something like that but related to the total length.
This failed when I tried to change more than 1 of them to 3 dec places.
{"count":26,"Sensor_1_Power":0.000,"Sensor_2_Power":1.1,"Sensor_3_Power":2.2,"Running_Average":2.1}
This works.
{"count":185,"S_1_Power":0.005,"S_2_Power":1.111,"S_3_Power":2.222,"Run_Avg":2.222}

What I do not understand is what that had to do with the ESP32 resetting every 4 minutes.

Regards,
Bob

Hi Bob

Sorry, I am unable due to travel to open up charts at present.

With ESP32s I find it a good idea to keep it attached to the PC used to program it. Then after programming run a terminal program on the port to see the dumps.

They very often show a clue as to why a reset occurred, and many times it is "watchdog" related. Your program takes too long to do something for whatever reason forcing reset.

I will also frequently enable a UART on that port to send out debug info. For example if I enter Macro ABC I may send out something like "ABC....." when it enters then add "OK" or something upon exit.

If something bad happens I have a clue as to where in the chart.

Regards

Hi,
I did have a terminal program connected to that port for debugging (Thanks Martin) but I could not figure out what had happened. The weird thing is that it was pretty regular and luckily resolved when I sorted this issue out.

Regards,
Bob