ChipChop Support Forum
Log in
Log out
Join the forum
My Details
REPLIES: 4
VIEWS: 222
BACK
REPLY TO THIS POST
Hossrod
19 Feb 2024
Feature Request: Server side value storage
@Gizmo

The more I'm getting into things, I'm finding it could be very beneficial if I could somehow store values that my device could read. They could be simple constant name|value pairs. Things like threshold values, boundary values, limit values, IDs, tokens, etc.

For example, lets say I'm logging temp and humidity sensor values to google sheets. In addition to logging, I'm also acting on those sensor readings (firing events, printing on a display, turning on an LED, etc) based on debounce boundaries, value thresholds, etc.

Rather than hard code those values, spreadsheet ID, base URLs, etc, it would be awesome if I could enter such values into Dev Console that my devices code could read at startup, or from a device push event manually trigged from Dev Console.

This way I can fine tune and adjust such settings without having to make a code change and deploy to device. It also allows me to keep ID/Tokens/etc stored centrally (and available to all my devices) and not buried in my devices code.

Think it would be good to have global values (any device in the account can access) and device level values (only the current device can access).

In device, I imagine getting them something like...


// For current device vars
ChipChop.getDeviceVars(); // Get all vars (array)
ChipChop.getDeviceVars("DebounceTimer"); // Get a specific var by name

// For global vars
ChipChop.getGlobalVars(); // Get all vars (array)
ChipChop.getGlobalVars("SomeToken"); // Get a specific var by name


I would probably request them after ChipChop connects. After that point, probably only request them after getting a request to do so from me using the send command to entire device feature for example.

I dont think there would be need to write to the values from device code.

Thanks for hearing me out IoT slayer!
jnogues
19 Feb 2024

Good idea! I'm already waiting for it be implemented!

Gizmo
19 Feb 2024

oh, that's easy on an ESP. I do it all the time just bit more manually :-)

I guess it would be helpful for the library to handle that for you even if you are experienced, no reason why not, except that I would have to definitely start considering splitting the library into ESP specific and like Arduino generic.

I am a bit worried about publishing updates to the library almost on a weekly basis. There is about ten of you guys that I am constantly chatting over email and you like to experiment with new things (no idea why but great for me, it keeps the challenges coming!)

So, I'll start just emailing you every time I implement something new and once it's tested I'll publish it...deal?

Back to the "default settings" topic:

- Currently the way I do it is by simply sending a command from the web app to the entire device as a string and I split the command like:
initTemp#34
download_update#http://chipchop.io/smart_light/firmware.bin
sensor_treshold#956
..etc

and then on the device if I get the target_component = "any", I split the string by "#" and the first part is the setting and second is the value

and then save all that in the local flash so when the device restarts it can load the default values even without wifi, and if not it connects to ChipChop and waits to receive the settings for the first time.

But, yes, that requires a lot of extra code and I completely agree that having a simple initial settings that can be requested on demand would make things a lot easier.

The library side of the code is not a problem and I can write that in 15 minutes, it's the server side that would require an expansion to the database for all devices and I have to be carful as one some servers there are few thousand live connections in every millisecond and the database restructuring could take 50-60 milliseconds that can get messed up with live data coming in.

Actually, I am talking shit, just figured I can do it 🤓

Ok, I'll put this on the list, there is one more thing I want to add anyway for mr @DownUnder so may as well implement this too at the same time.

Will let you all know


Hossrod
20 Feb 2024



Attached images
kennyFx
20 Feb 2024

I'm on the waiting list