Here is the control screen capture …
I would like to be pulling the default value from a device tag, which is subsequently set to the new tag value in the Virtual Button triggered workflow using the Device: Update node (this node already accommodates both attributes and tags).
Thanks
You’re definitely not the first to ask for this functionality and it is already a ticket. It looks like you’re using the control to update a set point, which is then stored on a device tag. That use case makes a lot of sense!
Thank you Brandon. User adjust-ability of device configuration (setpoints etc implemented with device tags) is exactly the use case.
Conversely … it is not clear to me how an input control to change the value of a device attribute (state) would be useful for anything but debugging?
It’s less so “Use this control to change the state value” than it is “Use this control to turn the lights on - because the block indicates they are currently off - which in turn will cause the state value to change from off to on.” Because when you push the button, you are really either sending a device command or triggering a workflow virtual button.
Does that make sense?
Thanks Dylan. IIRC my views are aligned with typical IETF practices. Turning device behavior on or off … that is configuration and I am thinking device tag for that. Attributes align with the IETF notion for status reporting of operational data from the device.
I’ve got a set of new-in-box cowbells I can offer as reward for pushing this feature to the top of your pile.
I’m considering a work-around until you are able to address this ticket. If I switch these “configuration” tags and associated workflow logic over to device attributes, does that mean these seldom changing configuration values (now attributes) will be sucking up space in your time series database?
Attributes are a perfectly good workaround. I don’t see any concern over using up time-series storage for these.
And … almost.
I added “mirror” attributes into which the actual tag values are copied when Device State is updated. The specific reason for that being to allow the Input Control dynamic values to initialize from the tag values.
The Input Control does not seem to be updating properly. I have a Device List which links a dashboard with context for a specific device. The dashboard (couple dozen blocks) displays properly for the specific device context EXCEPT the Input Control dynamic values. Only after I do a manual browser reload of the entire dashboard page do the Input Control dynamic values display properly for the specific device. Until I do that, it is either displaying the defaults or (worse) the values from the previously displayed device but with the correctly displayed device name in the header (pulled from the context).
I am also seeing spaces being injected at the front of dynamic control string values.
I’m looking at this same issue currently.
Is there a solution to using device Tags in the input block?
Or is writing these to attributes the best current workaround?
Many thanks,
Chris
Hi @ChrisGM,
You are correct, using attributes is the best current workaround as this ticket is still open.
I will, though, add your +1 to this ticket and keep you updated with any information I learn about it.
Thank you,
Heath
Hello,
Has anyone integrated max30100 sensor to losant, I am having issues with uploading to the losant dashboard.
Hello,
This max30100 sensor is having some bugs uploading its data to losant dashboard.
This happens with the device.connect() method.
I am using arduino idea for prototyping. Can you assist me?
Warmest regards,
Sunny
I replied here: Max30100 sensor not reporting to losant - #2 by Heath
Let’s continue the discussion in that thread.
Thank you,
Heath
