I understand that edge workflows can use storage but you cannot set, view or create it there.
[Edge Workflows | Losant Documentation]
Where does Edge storage get created, or does that happen with the Set Storage node ~ which for me is throwing an error. In regular workflows you create them first and can then reference them in workflows. Please advise.??
First, what error is the Storage: Set Node throwing? I would not expect that to error under normal circumstances.
As for cloud-side workflows, while you can directly set storage values through the API and user interface, most use cases revolve around using the Storage: Set Node in one run and retrieving that value using the Storage: Get Node in a separate run. Think increments or tracking of if a process already occurred. The use case is the same for edge workflows, just without the ability to store or retrieve a value using the Losant API.
You can, however, add the ability to get or set values by adding nodes to your edge workflow. Something like a Virtual Button to a Storage: Set Value Node to set a value, and a Virtual Button to a Storage: Get Value Node, connected to a Debug Node, to view its current value.
Undefined value
It wasn’t the storage value, it was the payload, i usually copy payload path, that’s a little different when working with Edge Workflows.
Opened second window, copied and no errors.
While I am now not getting an error, I am unable to set the Device State updates to the values.
I for example… I store with “Storage: Set Value”, Store Number, key:storedhumidity, value {{ Weather.body.current.humidity }}
In the “Device: State” node, all my non-storage attributes are updating, but none of the attributes that store in storage are. For example I have a device attribute called humidity, and I am trying to store {{ storedhumidity }} but I don’t see it in payload.
Values set in workflow storage are not automatically available in your workflow payload; instead they must be retrieved using a Storage: Get Value Node and added to your payload at a path of your choosing. This is because workflow storage values can get quite large, which could lead to payload size restriction limits if everything from storage was available on the payload at all times.
Based on your description here, I’m not sure using workflow storage is even necessary, though; if you are getting a value in a run to set in storage, can you not immediately then just report that value using a Device: State Node? Or are you collecting these values from sensors on irregular intervals and are then reporting several attributes at once in a later workflow run?
If you’d like to post a screenshot or an export of the workflow, I may be able to help further. Just make sure what you provide does not expose any sensitive credentials.
Derp 
That makes sense. Will try it now.
Reason: Running in Edge Gateway, updating energy information from a power meter.
Want to collect weather data but a much lower interval, so have a workflow running on 15 minute schedule that is updating temp, humidity, UV to storage keys. Don’t want to overload the weather API with the same polling interval of power meter.
If there is better way to show weather data alongside device data, please advise.
Weather data every 15 minutes is a good idea, as it’s unlikely to change much over that time and you are making what are probably rate-limited calls to a third-party service.
How often are you collecting the power meter data? Do you want the weather data to always be available in the same timestamp alongside the power meter data? If so, then your idea of using workflow storage to hold the weather API’s values is what I would recommend. You would then need to use a Storage: Get Value Node to retrieve the latest values (which were set by a Storage: Set Value Node) and report all values together.
Here’s another option, which would be resilient but would utilize more payloads …
On the edge, you collect your power meter data as needed and report it as device state by itself.
In an application (cloud) workflow, that’s where you do your periodic fetching of weather data and holding it in workflow storage.
Then, in the same application workflow, use a Device: State Trigger configured to fire for your device(s) and power meter attribute, and using a Device: State Node, record the weather data at the same timestamp as the power meter data.
The downside is now you’re using 2+ billable payloads per power meter reading …
The benefit is, on the edge, if your HTTP request to fetch the weather data fails - most likely because the hardware lost internet connectivity - then your weather data may be out of date. (Your power meter state reports will automatically queue and replay when the device regains a connection to Losant’s MQTT broker, but the HTTP Node will not.) That problem is much less likely to occur in a cloud-based environment, where the internet connectivity is near 100%.
Anyways, not a deal-breaker but I thought I’d offer the alternative solution.