Dashboard changes Generic Analog Input name


#1

Thank you for taking the time to submit your bug/issue! Please use the points below as a guide when submitting.

  • Device & model you are using (Ex: Pi 2 Model B or Arduino Uno with W5100 ethernet shield)
    ESP-12f

  • What dashboard are you using? (Web, iOS, Android)
    Web

  • Please describe the bug / issue as detailed as possible. Attaching the code and any relevant screenshots would be very helpful!
    Created a Generic Analog Input widget and renamed it to Temperature. The dashboard keeps changing the name back to Analog Input. Below is a screen shot half way through the transformation. If I refresh later the widget itself will also say Analog Input. The only difference between Temperature and Humidity and Heat Index is that Temperature has a trigger associated with it as well.


#2

Hey @ats1080s,

I’m struggling to reproduce this on our end. Does it happen with any generic analog input widget on any of your Arduino devices, or just the ones under that ESP device entry? Or specifically, just the one you’ve shown in the image?

If the latter, does it go away if you delete that widget and re-create it?


#3

I’ve deleted and re-created a few times, so that doesn’t work. The full process is this:

  1. Add new generic analog device with settings below

(can’t remember if I did 2 or 3 first)
2. Rename widget by clicking the settings button then settings and change the widget name.
3. Create a trigger by clicking on the settings button on the widget and click trigger. Drag in the device then click the dropdown and it will says Analog Input (for me anyway)
4. After a while a refresh will start changing the names back to Analog Input.

I’ll send you my password in a PM so you can see it then just let me know when you’re done and I’ll delete and try again to make sure I have 2 and 3 in the correct order. Currently the widget name is correct in the dashboard as Temperature but if you click settings it shows up as Analog Input. Tried on Firefox and Chrome so it’s not a cache issue.


#4

Thanks for the more detailed info (and the temporary access to your account, you’re welcome to change the password back).

I can reproduce now on my own account. It appears that it’s related to the device being offline, I can reproduce on any random Arduino on my account as long as the device is offline when renaming the widget. This is enough to take it to our QA team, I appreciate it.

Give it a shot with the parent device online and it looks like it will retain the name change.


#5

Ah, ok. That would explain it since it’s usually only online for about 10 seconds at a time during the upload.


#6

Yeah makes sense. It’s absolutely a bug, just hoping that provides a workaround until we can get better behavior renaming while offline.


#7

I waited until it came back online to change the name. Looks like it worked, thanks!


#8

Cool. I’m going to mark your issue as resolved, but for the record when future people find this thread, we still need to fix the issue rather than working around it, and are planning that now.


#9

Just to update here, we’re going to change the dashboard so you can’t rename widgets while the device is offline, which will effectively avoid this issue.


#10

I’m not sure what all is involved in the back end so this might not be possible, but I think the best option here would be to cache these changes and upload when the device comes online. That way the dashboard looks the way you want it to look and when it comes back online it’s just automagically ready to go. The battery powered project I’m working on now is a great example of where this would be almost required. I had to look at the last time it was online and then when it got within 2 minutes of the next 10 minute wake and sit there and stare at the LED to see when it blinked to turn on then scramble to update the name before it went back to sleep.


#11

Just wanted to let you know that I’ve added your comments to the internal tracker for this issue. I think its a valid point and use case. This may be one of those scenarios where we make the quick fix to avoid the bug, then revisit and do it better when we have development time.