Is ezdata working or not?

[felmue]

Hello @Dominikcnc

sorry no, seems to be broken still. Even counting up one every 10 seconds makes my M5Core2 (v1.10.0) crash (error 23) after about 8 counts.

@m5stack : hey guys, what are we doing wrong? Is there a limit about the update frequency? What are we missing?

Thanks
Felix

[Dominikcnc]

@felmue It is strange that you can not communicate with the server. In my case the program works up to 8sec and gets error 23.
I'm disappointed because I bought 3 Core2 devices and sensors that I can't use now and probably won't be able to return them anymore

[felmue]

Hello @Dominikcnc

actually I think I see the same as you. I count up (every 10 seconds) and after about 80 seconds (count is 8) I get error 23.

Thanks
Felix

[ajb2k3]

@felmue error 23 is normally a trusted security warning.

I haven't tested lately because I have been busy but I get get errors if you tried to post too quickly.

@Dominikcnc I have no problems using the Core2 AWS with AWS/Azure and a self hosted MQTT/Nodered service on a Raspberry pi

[Dominikcnc]

@ajb2k3 I have managed to connect to the AWS platform so far. I can send and receive information, only I do not know at this point how to make it publicly accessible and with graphs over time. I bought core2 because it was advertised as a great and easy to program device for everyone, and here it turns out that such a basic flaw has not been solved for over a year.
Thanks to your advice I increased the time in the loop to 25 seconds and so far it works (still testing). Unfortunately for one value. My project assumes 7 values from the temperature sensors, so I will have to refresh the loop every 3 minutes :)

[ajb2k3]

@dominikcnc I am working on a new book for the core 2 thanks to feedback from everyone about the first book. Time willing, I may be able to look into the issues over the holiday.

[Dominikcnc]

@ajb2k3 I didn't even know there was such a cool guide and I'm waiting for the second book. Good luck :)
I've played with the core2 device a bit and I'm not quite satisfied. The connection with ezData is not stable enough and I keep getting errors. I tried to increase the time of sending information to 2 minute between writes and with such a configuration I managed to strim the longest for 30h. I used the start timer and timer callback functions for this.
Now I made a program that uses the If function and sends information every 60 seconds. So far it has been working stably for 24h. @felmue forward

[Greoj]

@dominikcnc
You will have a more stable program if you use the asynchron EzData functions.
They are unfortunately not mentioned in the "documentation", but they are available in the M5Stack Flow interface. The main difference is that the asynchron functions implement a python callback function in the background (also accessible in the Flow view) to capture possible errors.
In my case I got frequent error "23" with the synchron Ezdaza functions.
As with all M5Stack flow interface functions there is no python exception handling implemented.
Therefore I had trouble with frequent program stops until I framed the EzData python functions in a TRY/EXCEPT block within an "execute" block.
However, later I discovered the asynchron EzData functions which will actually do this job.
Even better is that they do not slow down the main program flow which in my case detects the ticks and speed of my old Ferraris energy meter.
Note that in case of an error the value that you tried to push to the EzData queue is simply not stored.

Example of the asynchron EzData functions:

[Dominikcnc]

@greoj, your suggestion was incredibly helpful. With my previous example, I was able to achieve 9 days of continuous operation without any suspensions. Now, with the asynchron ezData function, I'm able to record data on load every 5 seconds and it's working great. When errors pop up, the program continues to work and is able to start recording values again after a while. I think you managed to solve the problem. I'll let @ajb2k3, @lmartu68 and @felmue know."

[ajb2k3]

What Kind of errors are you getting?
When I ran mine connected to a terminal I was getting memory errors which could be reduced by adding a code block with:

import gc
gc.collect()

To the beginning of the main loop.

[seven53]

Good morning,
I find myself with the same problem and despite the solutions provided, I can only send 9 data packets before the synchronization stops.
Do you have a new solution?