sorry about lack of progress. tired. brain go-slow. I can carry on with LN/W800 tomorrow if wanted. My W600 isn't ideal for testing sensors (Air602 is in the post though).
BL602 started with command:
Code: Text
Log in, to see the code
I can do XR809 but still need to remove XR3 from P06 device.
Added after 29 [minutes]:
Added after 1 [minutes]:
would need sensor driver too (AHT, SHT or 83XX) I guess. Unless I did it on LED channel and flicked them on and off for a while?
W800 uses DISABLE_ALL_DRIVERS so you need to do some tweaks to allow loading and using drivers at all.
I locally enabled this to use DS1820, so it's working for me as long as I define DS1820, too.
XR809 is the same, but I never tried to enable it here, for I don't have any of those modules...
I just took their presence in your zip as a sign they were good to be tested
... and you were absolutely right, it should have been that way!
I just didn't consider that I started with a new checkout that didn't include my local changes.
So, let's try again, also (brand new and never tested) a version for XR809 ...
Good job on testing, altough I wouldn't focus on XR809. The first thing I would check would be the buffer wrap around, so, setup a buffer with like 30 samples and wait 31 cycles and see if the samples are still in order. Then wait 60 cycles, etc.
I know XR809 isn't the focus, but this on the bench right now for other work.
not sure how far I can get with no ntp driver. shall I forget XR809?
this is me toggling switches manually.
same backlog single line of commands as BL602 above. it's filling the bottom with sample dots and the pattern moves off the the left without issue. Not sure if this the test you're looking for.
Thats fine, thanks. If the chart is drawn, that's all we need to know, for the handling of data is the same for all devices.
I didn't want to focus on XR809, it was only a good opportunity to test the idea of a "reduced" driver support for devices with DISABLE_ALL_DRIVERS.
I came to the same situation while doing the DS1820 driver for W800 and used it again here for the charts driver.
It's simply allowing three functions: starting a driver, calling "on every second" and adding HTML to status page.
So your feedback is very helpful for me, showing it works for different platforms.
Details filled in soon, it's just three lines or so.
#define OBK_DISABLE_ALL_DRIVERS 1
// Even with OBK_DISABLE_ALL_DRIVERS defined
// allow to start a driver and display on HTML Page:
// enables:
// DRV_OnEverySecond(); and DRV_Generic_Init(); in usr_main.c
// DRV_AppendInformationToHTTPIndexPage(request); in http_fns.c
// used for charts driver
#define OBK_ALLOW_DRIVERS_START 1
and two changes to the actual code for the new "#define OBK_ALLOW_DRIVERS_START" in http_fns.c
cheers. that gives me a single straight line on W800. This is even more manual but still serves to demonstrate:
Code: Text
Log in, to see the code
W800 startup command doesn't seem to support very long strings, so has to be run from WebApp.
seems stable. not eating memory
Is leaving that above command running overnight on several platforms a worthy test or are you pretty confident at this point and PR is ready for merging?
Ah, thanks. I didn't take into account, that y axis isn't f type "time", but only "labels", so even if you add something for the same timestamp again later, it will just "go back in time", but adding it to the right of the chart. So my calculation of a "running clock" was just overdone...
Since allocation of memory for the ring buffer is done once on start of charts driver, I wouldn't expect a memory leak over the time from the charts driver.
From my point of view, this is "ready for production".
If you would like to do some more testing, maybe the implementation with a separate circular buffer in PR #1358.
Since this will again need changes to sdk Makefiles, I will attach some of the versions not in artifacts here...
Yes, thanks, that would be great - and a little "long time test" would be even better...
Another possible test could also be a "small" chart and testing "by hand" (or so slow, that it can be observed), if adding points will be o.k on the crucial points:
with a few points
when all points are used and its "rolling over"
I appreciate this is only one test, but I'll leave this W600 going all night. Shows W600 working anyway.
Added after 7 [hours] 35 [minutes]:
so this may not have anything to do with Charts driver, but W600 is unresponsive this morning.
Code: Text
Log in, to see the code
the following was true:
-web app logs page was left open in the browser
-OBK main GUI with chart drawing was left open in another tab
-the device is still responding to pings
These are the last logs visible
Code: Text
Log in, to see the code
I'll start W600 again but with no pages left open.
newbie question: how do I plot $power and $voltage variables every 5 sec in a chart (I managed to get the driver-enabled firmware on my BK7231N LSC power metering plug)
My autoexec.bat:
Is calculating possible at all for W600 in actual configuration?
I'm not sure, but wasn't there a define needed for this, that was not obvious in the first place?
Maybe #define ENABLE_EXPAND_CONSTANT
The drive is not enabled for all platforms. The line you mention (line 79) belongs to the Windows build.
Which device are you trying?
Added after 8 [minutes]:
jkwim wrote:
So next step is for you to approve it only for automatic build? Am I understanding the process correctly?
Yes, that's the way.
If you can live with an older version, you can scan the last PRs, iirc there were quite some for enabling graphs on different platforms...
The OpenBeken firmware introduces a configurable and scriptable charts driver enabling visualization of multiple variables with multiple axes directly on supported devices without requiring Home Assistant. The driver supports platforms based on BK7231T, BK7231N, BK7231M, T34, BL2028N, XR809, W800, LN882H, BL602, and others. Users configure charts via commands such as chart_create, chart_setVar, chart_setAxis, and addRepeatingEvent to plot variables like temperature, humidity, voltage, and power. Initial issues included crashes due to missing null checks in chart_setVar and chart_setAxis before chart_create, heap corruption from uninitialized memory, and platform-specific bugs such as vsnprintf handling null pointers. These were addressed through patches adding null checks, memory zeroing, and input validation to prevent crashes on invalid indexes. The charts driver was integrated with a ring buffer for data storage, with ongoing improvements to reduce flickering by updating charts instead of recreating them, and repositioning the chart below the "state" div to avoid page scroll jumps. Users reported stable long-term operation on various devices, including W600 and BL602, with some platform-specific driver enablement required in obk_config.h and Makefiles. The Windows simulator supports testing charts, facilitating development. Suggestions for future enhancements include adding a DIFF function to compute differences between consecutive samples. The driver supports variable expansion (e.g., $voltage*0.1) if ENABLE_EXPAND_CONSTANT is enabled. Sample configurations and troubleshooting tips were shared, including manual command sequences to generate pseudo-random data for testing. The charts driver is now considered production-ready with ongoing refinements and cross-platform support. Summary generated by the language model.