markv58

That and a couple of other reasons is why I created the thing. I'm glad you and others are finding it useful.

All this focus on the Temperature part of Virtual when the real brilliance is the few lines of code that create the Virtual Switch! You can create a switch, add it to a scene and turn it on and off with the scene and now you have a way to see if the scene is on or off. You can use the ISY rest interface, which you can not use to poll a scene. You can use the switch in a program, If Kitchen Lights Switch is On, Then / Else. You can't do If Kitchen Lights Scene is On, not there, no way, can't be done. You can create a switch and use it to control a folder full of programs. I have a folder for Away Mode, in it are programs that run lights and TVs and other devices automatically. When the Away Mode Switch is On it allows the all of those programs in the folder to run.

You will update the nodeserver then update profile then restart the AC. You will not need the programs anymore, you can set each node to go and get the data you want from any variable you want. Raw data is converted automatically if variable prec is set to 1. You can use your existing custom config params as they are with no modifications. I have everything working Push and Pull. Testing and refining for a bit then for the data storage and retrieval part. That will retrieve your node settings and last stored data if you restart the nodeserver. The data will be stored after each update.

After various configurations I'm thinking this should be about right, what say you? You get 2 actions so you can Push and Pull or Nothing as well as switches for Raw to Prec and C to F.

I have worked out the method to pull values from variables and parse out the data so yes @Teken you should be able to see Brultech data in the AC, eventually. The first node to implement all of this will be the Temperaturec node for testing and evaluation. Once that node is locked down solid then I will migrate the methods to the other nodes. The node will be able to check the selected variable on a regular basis and pull the data in, including the Prec, which may help automate the Raw data conversion.

No, v1.0.8 sends back the exact same data in its original form so the program isn't triggered again. Any data manipulated and displayed is only in the node with original data preserved. v1.0.9 and beyond will only push data to a variable if you initiate the push. I am also working on a method to pull data from variables that may negate the need for programs.

This all works, anything else?

@Teken @MWareman I am working on the average temp, resetting High and Low, restoring previous values to High, Low and Avg to back off an unintended button press. A way to set state and integer variables on the fly and push to value or init. Once these things are working I will setup the archiving and retrieval process. I'm only doing this to the TemperatureC node for testing so that will be the first update, if all goes well, updating the Temperature node will be quick. This will take a few days with limited time at my desk but it's already well underway and I expect to start testing soon. @MWareman You don't need a second variable, simply set the node to the same variable and have a program push the variable value to the Temperature node for conversion and display. Your data in the variable from the Brultech will be unaffected. @Teken Thank you for helping with some of the tech support! It is very much appreciated!

@Teken Reset High and Low temps will be in next update. When you asked about an average temp, avg of current / previous or highest / lowest ? Is an average even useful?

@bfish Short and long polls are seconds.

Make sure you are on v1.0.8

Yes, I will get that worked in. I'm out in the field today so I'll need you to answer questions for a while, just don't get me in too much trouble.

The values should not change with a nodeserver restart, I haven't tested to see what happens with an ISY reboot but the values will probably blank until populated by any program. A future version will archive all values so that they will be retrieved at the nodeserver restart and thus, not lost.

1.0.7 only effected the temperaturec node, 1.0.8 will do the same to the temperature node and should show up within the hour.

Virtual v1.0.8 Update: Temperature node mirrors Temperaturec node with Highest and Lowest, Since Last Update and a function to Convert Raw to Prec, it appears that Brultech is sending raw data to state variable, so that can be converted. The short poll, set to 30 seconds, updates the Since Last Update value and can be changed in the Custom Configuration Parameters. Also changed the restart code as to not effect the Highest and Lowest values in the AC. Update Profile and restart the AC after the update. The Highest and Lowest values update when the next temperature update happens to accommodate data conversions, this is the normal procedure. There is currently no archiving of these values, so if ISY reboots, those values are lost. A future update will archive data.

The external device can simply set the Virtual Temperature node using the REST API - /rest/nodes/n016_142/cmd/setTemp/<temp> - will set the temperature same as setting the state variable. And setting the V Temp will push the <temp> to the state variable as well.

The purpose of the Temperature nodes is to pull temp data from various devices to the nodes and have the ability to sort the nodes together, in folders, etc. for easier viewing rather than having to search through a bunch of variables or tabs.

@MWareman You need a program to monitor a change to the variable then have the program set the Virtual Device value. Or you could use the Rest API to set the Virtual Device directly. /rest/nodes/n016_142/cmd/setTemp/<temp>

The value display is set to prec 1 if you send prec 1 or convert F to C.

Going to push v1.0.7, no one should have any trouble with the update. Make sure to Update Profile and restart the AC. If you want to kick start everything then run the Then part of your programs twice and all of the values will populate and make sense or just let it be and after the second update all will be well. This just updates the TempC node and I'm going to dig into node and see if I can trick it out.

After toying with Virtual for a while I am rethinking how it should work. The reason for the tie to variables is a way to store information about the device state and retrieve it from the init value should the ISY bounce. This is now becoming more difficult with the added data points in the TempC node. There may be a better way and with that a way to choose the variable in the node rather than something hard coded, if you need a variable at all. I may push what I have as an update but I am going to investigate this other path for a few days and see where it goes. If it all works out it should cut down on the number of programs need to manipulate values and retrieve them. I will tinker.

To display values in their proper format, if there is one, a specific uom is used for the Drivers (the boxes) that display info. I could just setup a bunch and then most any data could be sent. I will tinker.

@MWareman @Teken Unfortunately when I attempted the fifth node type I hit a brick wall, spent hours trying to get that done. Nearly lost my mind trying to figure out what comma or space or dot wasn't in the right place. There is the Generic Node that you can tag with generic and dimmer, I can add more variations or just let it be free form. The data is displayed with no formal format but if free form labels in the custom config params the node could be labeled watts or amps or volts or whatever. Still tinkering with the TempC node trying to get it to wash Tekens car.

@Teken Kinda like watching paint dry but not as fun:

Tinkered: Checked with the short poll every 30 seconds and reset by a Temp change. Max allowed is 1440 which is a day, a program could notify you of a problem.