This has led me to start using, where security or "non-mission-critical" applications permit, wifi-based devices with http command sets. Examples are Neo blinds (where I created devices using action groups running simple scripts) and Shelley devices (which are not locally certified, and take some time to find their way to Australia as there is no local distributor). Fortunately, those with much greater coding skills have developed plug-ins for both the Neo and Shelley devices.
More recently, there have been devices appearing on our local market, particularly wall switches and wall outlets, that are certified for local use, and are readily flashed to use the Tasmota firmware. I am aware that these have been integrated into Indigo using a number of MQTT plugins. However, these appear to be complex (beyond my skill set!) and require the presence of an MQTT broker
Having scoured the plug-in store, there are a number of plugins that come close, but still require a number of actions and/or triggers to implement. Examples are the Virtual Devices Extension, but this has no feedback of device status - which in many cases might be achieved with further actions and triggers using other plugins such as Ghost XML.
This has led me to wonder (for which I have had plenty of time in our Stage 4 COVID lockdown!!) why (and if) a Tasmota-specific plugin has/could not be readily developed as has been done for Shelly and other wifi devices. A little more wondering has led me to the possibility of someone (much smarter than me!) developing a more comprehensive "swiss-army" virtual device (SAVD!
) that could be configured by the end user - inserting http commands for on/off/dim, etc and configuring custom device states to reflect device responses and/or regular updates of device state(s). There is a hint of such a development in the description of the in-built Indigo virtual device.I would be interested in informed comment about the possibility of either of these "wonderings"!
Thanks,
mclass