I am wondering what MyDevices is doing to interact with code running in the background.
Say I already have some implemented code that works well and there isn’t really time to integrate a driver into Cayenne directly, but I want to benefit from the great GUI widgets and Cloud connectivity.
Would it be appropriate to have an option on all widgets to interact with simple files instead?
For example:
Read file when changed, update result in widget.
Code behind reads command file when changed, and processes it.
Could use a simple JSON schema to keep things modern. In fact, you’re probably already using this - just dump it to a file.
It’s stupidly simple and not fancy, but allows us to connect to existing code very easily and takes MyDevices clearly out of the support roll for user code.
The widget could have a check box to say “Use File IO”, then a box to put in the path to a directory that has a set of files in the expected format.
Also just thinking if we had this, we could start developing more interesting functionality immediately and the team can decide whether this should be implemented at a higher level and assign resources to develop it.
Me too…
I am looking for a pretty direct and simple Generic Variable data idea that link real or imaginary numbers and pass thhem though: From Pi <> Cayenne. Say a function, library etc… Nearly all my projects will rely on this sort of thing opening up.
I have suggest two methods of ‘jumping the fence’ one being the above and the other being a window / sand box / play pen where a bit of python that can be run within a Tab in Cayenne the Pi etc
So in my test model, a bbq controller. I would just need input from Cayenne for setpoints, and a way to display temperatures in the widgets using say file I/O. The code behind logic will handle the PID control loops.
Which brings up another interesting thing that necessitates a switch that isn’t tied to IO. If I have automation in the background, I don’t want the control of my physical I/O in Cayenne. If you want to shutoff for instance, You would press the off button, but I want the fan to run until the bbq cools down for instance.
I don’t know if it’s on your backlog or not, but it would be nice to be able to display a setpoint and limit lines for the analog widget on either the gauge or graph… and have them as dynamically set variables because they can change.
Then think about how we can take a value from a knob or slider and have it feed the setpoint or limit lines.
I think I’m following you here. Does this mock up make sense to you then? You would chose the option to specify the file node location in the widget settings.
Can you expand a little bit on set points and limit lines? What would be an example of a set point and a limit line? How would you envision it working in Cayenne? Maybe just go into a little more detail into your BBQ use case…Just trying to make sure I understand before I run this by the design team
Sorry, I was in an all hands town hall yesterday on SCADA and Control systems.
I don’t understand how the Arduino stuff works, but in the mockup, I think that would work.
In the GPIO drop down, you would select, “Use File” or something like that. For the Channel drop down, you’d select the path. If we want it to be a simple selection, you could instruct us where the File I/O stuff should go, then the drop down fills in itself. That would work!
So very briefly how a pellet smoker works is there is a hopper full of wood pellets that gets augered into a hot box at a controlled rate. The hot box has an ignitor that glows red hot when initiated starting the pellets on fire. A fan blows through holes in the hot box circulating heat and smoke through the convection chamber.
So from cold, here are the actions to take.
Press Start to turn on fan, turn on ignitor, and turn on auger at initial feed rate (on 5 seconds/ off 30 seconds - on repeat).
After 10 minutes, turn off ignitor.
Monitor temperature and slow down feed rate as temperature reaches setpoint (use PID algorithm).
Maintain temperature by increasing or reducing feed rate
on 5 seconds/off 10 seconds would be fast, on 5 seconds/off 180 seconds would be slow, for instance.
Also monitor food temperature, and alert when setpoint is near, and when done.
Monitor hopper empty switch, and alert when empty.
Potentially monitor external temperature as additional datapoint in improving PID algorithm.
When done, user presses Stop button, turning off auger. Fan stays on until temperature falls below cool setpoint or after X minutes.
So if we wanted to plot that, it would be nice to be able to show the chamber temperature and it’s setpoint on one graph. Also food temperature and setpoint on another graph, or better both setpoints and both temperatures on the same graph. Also, it would be nice to show limit lines to show HEY! You have a grease fire, and trigger a physical alarm and email, or indicate that you’ve got another 100 degrees to cool before you can put the cover back on. Also an alert.
Is that clearer?
Here’s an Example of what I’m talking about for OctoPrint.
in reading through this idea it looks like this discussion has morphed into two separate concepts.
The first one is to be able to interact with files on the pi (read or write a value from/to a file) which would give us the ability to link our own code which may or may not already exist to the Cayenne world. I would heartily vote for this suggestion! it would open up a whole world of possibilities!
The second idea is to have easily modifiable and displayed reference lines on the graphs. Again a great idea and something that I think should be on the list, but I would put the file access higher priority (just my vote ).
I wasn’t feeling great this weekend and was trying to develop a WebIOPi SPI driver for a MAX chip.
The development guide was quite daunting, so decided to give up and have a homebrew instead.
There is a great driver using bit banged GPIO, but for efficiency, it should be using the built in SPI HW interface.
Having file i/o will allow us to get things done with whatever glue logic we can come up with, then code for efficiency if necessary later. Also, many of my projects I want soft buttons vs. driving I/O directly, as there is logic to deal with.
ie. Don’t shut off the fan until the temperature drops, else Chernobyl.
