[superchart widget] Extend "connect missing data points" strategy

hey,
here’s my use case: I have an AC fan, with 4 possible states (fan speed). What I’m trying to plot is the current fan speed with only pushing the pin value on state change.
Now, the current strategy simply connects the 2 data points by a direct line like this:

What I’m looking for is a different strategy, which would connect them like this:

I think the binary style is pretty close to what I’m after, however…well, it’s binary, so it only allows to use 2 states (0||1).

Is there any way of achieving this now (without a need of pushing the same data over and over)?

I’ve edited your post to have both images in the same place, and bumped you up a level so the restriction isn’t a problem in future.

I think there may be a solution, which is to send the current value once every minute, using a timer.
However, there is an issue that you may not have thought about. Superchart’s maximum granularity for stored data is 1 minute. If it gets two values per minute it will average them, and save the result to the database. This means that if you switch from 3 to 2 and send both of these values during the same one minute period then you’ll get 2.5 saved in the database, which would make your chart look a bit screwy (maybe).
I guess you could store the maximum value that was used during each one minute period then write it to the Blynk server using a timer.

Pete.

Hey Pete,
thanks for the rank update and a rocket-fast reply.

However, the solution you proposed is exactly what i’m trying to avoid. I think it is a waste to populate DB by the repeating values. The skewed line caused by averaging could be overriden by using the Bar style in such case.

I wouldn’t worry about writing unnecessary values into the database, it’s not really an issue in my experience.

Pete.

Thinking about it again, I have a mqtt publish trigger attached to the pin write event, and I’m not sure I want to emit redundant messages every minute just to get the chart right. It would probably require me to dedicate a standalone Virtual pin just for the chart and set the logic accordingly.

Do you think my original request still qualifies as a valid RFE?

Why not? My devices push out uptime and RSSI MQTT messages every 5 seconds or so, and I have 20 odd devices running most of the time.
If you’re using MQTT then you should consider not running Blynk on your devices but using Node-Red and the Blynk plug-in for Node-Red.

Probably not, but the developers are working on Blynk 2.0 at the moment, so it would be a long wait anyway.

Pete.

I use node-red with blynk plugins, but I’m also running the esp8266-based boards with blynk running on them; then I use write_event nodes in node-red. The mqtt is pretty much a glue here.

What’s the recommended practice here? use some pure MQTT implementation straight on the devices?
I’m probably pulling this off the original topic, so we can close the thread afterwards.

Thanks!

Have a read of this:

Pete.

1 Like

Have you experimented with the bar style?

hey @daveblynk,
sure I did, but it does not come with the ‘connect missing data points’ option, so it produces gaps.

Anyway, per @PeteKnight’s suggestion, I added something like this [1] to my node-red flow
[1] Selection_067

to backfeed the pin value to the DB every minute (cron trigger set to every minute)

which produces something like this [2] with the classic line style:
[2]

I’m not really happy about this workaround, but I guess it’s currently the only way to go.

P.S. Pity that the android app is not open-sourced. I would try to make a contribution to this widget.

Would it help your peace of mind if you added an RBE node so that you only wrote the data to Blynk if the value had changed?
The ‘connect missing data points’ option in SuperChart should take care of the rest.

Pete.

That’s an interesting idea and I tried to explore it more.
While RBE node does not provide a way of publishing the old value, I made my own mechanism:

So, if a proper MQTT message is published, the flow directs the value of the AC fan mode to the function node:
[1]

var old_mode=context.get('old_mode') || ''
//node.warn(old_mode);
if (old_mode != ""){
    if(msg.payload != old_mode){
     msg['old_mode'] = old_mode;
     //node.warn(msg.payload);
    }
}
context.set('old_mode', msg.payload);
return msg;

… tl;dr, if the mode value differs from the previous one, the old one is attached to the old_mode property of the msg object.

The next node in the flow is a switch that simply checks for the existence of this property and contains 2 identical switch cases to split flow in 2 for such case:
[2] Selection_071

The first one replaces payload by the msg.old_mode and forwards the value to the V44 write node
[3] Selection_072
whereas the second one uses the new mode value and writes it to the same pin after some delay.

(note that i used completely different pin for this to be used just by the superchart widget, as the original pin might cause some loops as there are some write_event nodes attached to it).

This flow ensures that 2 consequent values are written on a state change with a really small delay between them.

And it works reasonably well …for the live data granularity:
432-768-max

but unfortunately not that well for the others (e.g. 30mins):
image.

I also tried to put varying delays to the flow without any effect. I guess with the minimum resolution of 1 minute, I might put in 1 minute delay, but that would cause some race conditions on multiple value changes inside that time window.

Anyway, I’ve learned a lot during this experiment so I don’t regret anything.