Add Checkbox to Distinguish Sensor Reference in "Value" Field

[desarrollador-06]

When configuring a iconify widget, I encountered an issue where entering certain text in the "Value" field resulted in the icon not rendering. After extensive debugging, I discovered that if the value matched the name of a selectable sensor, the draw function wouldn't receive the expected value. This behavior is controlled by the sensor boolean property in the configuration file. Disabling this property allowed the icon to render correctly.

To improve usability and avoid confusion:

1. Add a checkbox next to the "Value" field to indicate whether the entered text is a sensor reference or not.
   • If the user types a custom text, the checkbox should default to unchecked.
   • If the user selects a value from the sensor list, the checkbox should default to checked.
2. Allow users to manually toggle this checkbox to switch between using the field as a sensor reference or a plain text input.

This enhancement would make the behavior more intuitive and reduce the need for manual configuration changes in the underlying JSON file.

[tjaworski]

Interestingly, the original design included a checkbox, but I removed it because it added an unnecessary layer of complexity. I also think some widgets (e.g., iconify and image) probably shouldn’t display any sensors as selectable values, as those widgets can’t act on sensor values. I’ll need to give this some more thought. Thanks!

[zeedif]

I accidentally opened this issue with my secondary account. I actually think it’s a great idea to allow widgets to receive values emitted by sensors, as it would just require adjusting the sensor outputs to values the widget can process. For example, it could be used to display a different icon or image depending on the time (a sun for AM hours and a moon for PM hours). This is a simple example, but I hope my idea is clear.

[tjaworski]

Yes, but in that scenario, you would need to create a new widget with fields that adjust the widget’s behavior based on sensor input. In this case, the ‘value’ field would be used solely for selecting a sensor, while additional fields would manage properties like icon name, thresholds, colors, etc... The two fields, ‘format’ and ‘value,’ were intentionally designed to be as generic as possible to fit within the widget ecosystem, but they are not the only fields available for use.

[zeedif]

I wasn’t referring to creating a new widget, though allowing widgets to associate with sensors would certainly make it easier to transform values in a customized way, especially with a custom widget. However, I meant that even with the current Iconify widget, associating it with some of the existing sensors, like the time sensor, could be useful. For instance, by adding a case to the format switch so that, similar to how it returns "AM" and "PM," it could instead return strings like "day" and "night." With how the Iconify widget works, this would simply append to the API path and return the corresponding icons.

[tjaworski]

I understand what you’re saying, but I don’t think this can be achieved with a pure iconify widget. How would you tell iconify to switch the icon from day to night based on the current iconify settings? You would need a new widget, perhaps called ‘clock_icon,’ with additional fields like ‘day icon’ and ‘night icon.’ You could then set the value to the clock sensor and format it using {3}. The widget would display the day icon if it’s ‘AM’ and the night icon if it’s ‘PM’. modifying the existing iconify widget to handle these specials cases makes it less generic. I'll create a widget in the next release to show this use case.