Smart Virtual Thermostat
Smart Switch Plugin
I’ll add the Virtual thermostat to my list. What type of control are you looking from the “Smart Switch Plugin”.
- Garrett
Change time of auto run and on/off switch without dimming will be enough.
I’ll add this to my list. Since this is a more complex plugin, I can not guarantee that this will get added to the app. It may also require the developer of the plugin to add additional code to help me better support the plugin.
- Garrett
Looks like maker of virtual thermostat release new version of plugin and its reported properly in your app now. Working change temp and heat now.
Its also reporting properly in vera mobile for android
Brovo to the developer(s) of the plugin. Glad it is now working in my app! Thanks for reporting on the status.
- Garrett
[quote=“houk, post:5, topic:173870”]Looks like maker of virtual thermostat release new version of plugin and its reported properly in your app now. Working change temp and heat now.
Its also reporting properly in vera mobile for android[/quote]
Yep… I can confirm that it shows up in AutHomation as of V1.9 of the plugin. Houk: were you able to get it to read temperature sensor values? I was hoping to get it to read the temperature off one of my thermostats.
I don’t have any thermostats. I have 2 water pump thats working as binary: on and off. Temp reading is analog inputs from LM35 thermometer connected to TCP/IP device called Sterbox and reading it to vera with plugin based on garrettwp wswitch plugin 
Sterbox is also virtual binary output and managing pumps
And it’s working like a charm.
I hope you do not mind me thinking out loud …
In the case that you find devices that you do not currently understand, have you though about reading the full data from user_data2 request …
You can extract the controls array from the static json for the corresponding device type and dynamically generate a user interface. You can also locally cache a transformation of the controls data in a format suitable for you hashed by the device type … You would then only need to see user_data again if you ever found a new device type … maybe an option to flush this local cache in case the user knows they installed updates to a plugin.
It might not be pretty … but than you might get close to 100% compatibility with plugins … and you can focus on making the popular ones look fancy.
Richard,
There are several reasons why I did not go with user_data2. When I was first writing the app, I had code using user_data2, however the size of the data can be very very large. For example, user_data2 of my setup is about 664KB versus lu_sdata being only 20KB. To retrieve this data and parse it would take much longer than retrieving and parsing the lu_sdata. The down fall as you guessed it is that I do not have access to as much data. My goal of the app is to be efficient as possible and consume less data.
If I were to switch over to using user_data2, the app would require pretty much a complete rewrite (which I do not have the resources and time for).
- Garrett
@garrettwp
I was not proposing to change the basic structure of the application.
The proposal was only when you found devices that were NOT currently recognized.
And then you cash the info (controls list to devicetype) locally.
So a user would do this only when they installed a new plugin (device type).
Then the requests would be … can I have a better UI for plugin XXXX as opposed to
to can you support XXXX.
[quote=“RichardTSchaefer, post:11, topic:173870”] The proposal was only when you found devices that were NOT currently recognized.
[/quote]
Great idea, from my view add this functionality with refresh function when nonrecognition plugins change its version or manual option to re-download json options for one device like you did advanced info or switching to hidden.
In the just released version Garrett (who never ceases to amaze!) switched over to user_data2
nice work sir!