Displaying individual variables "as devices" (sort of like virtual devices)

[markv58]

@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?

[Teken]

@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?

@markv58

At a high level doing all of the ground work for averaging just makes sense and can be used in the other future virtual nodes.

For the temperature the average would apply to the high & low. For the Brultech energy data this would apply to all of them from Watts, Pulse, Temp, Voltage.

One thing I haven’t seen anyone do or ask before is having the ability to track how long or off something has been operating in a Node Server.

As of this writing I use the ISY Series Controller to track the run time for various appliances and hardware. In the past this was more in part for curiosity and seeing if I could. Later, this novel idea became the cornerstone of many of the safety systems within my home.

As it could tell me if the fridge / freezer was ajar, blocked vent, low Freon, to compressor.

During the extreme winters it tracks and alerts me of how long the furnace has been running. Julie U.S. will than verbally call out the increase vs expected runtime.

When the girls take endless hot baths and keep topping it up the HWT stays in heating mode for a very long time. Julie U.S. again calls out when that threshold has been exceeded.

Various fans are tracked and one thing I haven’t done are lights! Maybe this is a niche idea but if the next Node Server or even this one could count up / count down when say a switch is on - off.

That would have great value to me and hopefully to others. Perhaps my goal of off loading as many process heavy items from the ISY is the underlying need I suppose.

Thank You!


Sent from my iPhone using Tapatalk

[MWareman]

On 7/13/2020 at 8:39 AM, markv58 said:

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.

Agreed. There really shouldn't be a need to tie a virtual device to a variable in ISY. It could be persisted in Polyglot within the Mongodb. For me - this would mean no reliance on multiple variables (one for the poly to store it's value in - and a separate one for Brultech to send it's value to) - and two programs to send the data (one to divide the incoming value by 10 and store it in a temp variable - then to send it to the poly).

Adding more UOM options would likely be more viable at that point. I'm interested in options to send UOMs of 1,21,22,23,30,33,36,71,72 and 73 - though others may be useful to others in this regard. General just does not look as good as using the correct UOM to represent a value.

Thank you!

[markv58]

@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!

[markv58]

This all works, anything else?

[Teken]

This all works, anything else?

@markv58

If there was a bow down emoji to be used on the forums!!

Just for clarity will this new release allow those of us with a Brultech Dash Box (DB) be able to see the data now in the AC?

As I retasked one of my test boxes to send state variables to the ISY Series Controller and they show up and change. All of the required programs are in place. I selected both generic / dimmer but the AC did not reflect anything in the AC Virtual Node?

Hoping this release will see the REST calls from the DB. But am super confused as to why it matters since the data is being referenced from the state variable?!?


Sent from my iPhone using Tapatalk

[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.

I must be confused.

If the nodeserver is sending the value to a variable to store the value sent to it, but I trigger a program on the same variable changing and sending it’s value to the nodeserver - wouldn’t that create an infinite loop?

[markv58]

8 minutes ago, MWareman said:

wouldn’t that create an infinite loop?

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.

[MWareman]

Thank you!

Sent from my ONEPLUS A5000 using Tapatalk

[markv58]

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.

[markv58]

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.

[Teken]

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.

Ready to test when ready. I can simply update the Virtual Node Server and leave all existing programs in place and everything will just work?!?

Looks great and look forward to using this on the Brultech Dash Box as an interim break fix.

As an aside for those rocking a Brultech GEM, DB, energy monitor the team is slated to set aside time to develop their very own Energy Node Server.
@markv58

Much thanks for helping out bridge this third party energy monitoring / management need!


Sent from my iPhone using Tapatalk

[markv58]

2 minutes ago, Teken said:

Ready to test when ready. I can simply update the Virtual Node Server and leave all existing programs in place and everything will just work?!?

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.

[markv58]

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.

[carealtor]

4 hours ago, markv58 said:

All this focus on the Temperature part of Virtual when the real brilliance is the few lines of code that create the Virtual Switch!

 

Agreed.  And Thank You!  I can now get rid of my hidden keypads that I was using as banks of "virtual switches".

[markv58]

1 minute ago, carealtor said:

Agreed.  And Thank You!  I can now get rid of my hidden keypads that I was using as banks of "virtual switches".

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

[markv58]

Virtual v1.0.9 is ready for testing. I don't see any bugs so I am going to trigger the update.

This only effects the Temperaturec node until any bugs that pop up are chased off.

You don't need to change any custom config parameters that are temperaturec or temperaturecr. You can disable (recommended for now)  or delete programs that are sending data to a temperaturec node and pull the data from the node itself. The long poll sets the time between pulls and it will always need to be longer than the short poll. I recommend a 240 second long poll and 30 second short poll. Experiment and see what works best for you and let us know.

Resetting Statistics wipes out all values and starts from scratch however your settings are not affected. On the first run after a reset or updating the node needs to go through 2 cycles to fully update the page. Each time an update to the data occurs the data and settings are stored. Once stored a restart of the nodeserver will not erase data or setting, they are restored at start up.

There is a lot of logging in this update that will be removed after a thorough testing period.

Each node creates its own .db so you will see them if you browse the Virtual folder.

I have tested on RPi and Polisy with success.

Don't forget to Update Profile and restart the Admin Console

Best of luck to you and post any bugs, I'll squish-'em.

[markv58]

Virtual 1.0.10 Found a bug and fixed it, update requires nothing but a restart.

[tmorse305]

I upgraded to v1.0.9 but encountered the same problem I had with an earlier rev.  The display on the ISY side still looks like the earlier revision. Here's what I tried:

Update to v1.0.9

Restarted nodeserver confirmed it is running v1.0.9

Brought up the AC, did a Profile Update, closed AC

Restarted the AC, still shows the earlier version of the temp node, closed AC

Restarted Polyglot(RPI)

Brought up the AC, did a Profile Update, closed AC

Restarted the AC, still shows the earlier version of the temp node

Rebooted ISY

Brought up the AC, did a Profile Update, closed AC

Restarted the AC, still shows the earlier version of the temp node

What else can I try?  Thanks for your help.

(same result with v1.0.10)

[markv58]

@tmorse305 Sorry, the temperature node has not been updated only the temperaturec node, I will update that node next as soon as I can. 1.0.9 was some major work and I want to make sure it's operating properly before migrating the methods to the temperature node. I already discovered a bug and fixed it in 1.0.9   v1.0.10 is the current version and should show an update within the hour. Meanwhile take a look at the temperaturec node.

[MWareman]

I’ve got to ask - why polling ISY at all? Doesn’t ISY send the status real time for the Poly to see? I understand polling is used generally when the poly has to pull data from third party APIs...

My temperature probes temperature can change fairly quickly (I have sensors in my HVAC system) so I’d rather get changes pushed real time when they change than have to have the poly poll them.

[markv58]

5 minutes ago, MWareman said:

I’ve got to ask - why polling ISY at all? Doesn’t ISY send the status real time for the Poly to see? I understand polling is used generally when the poly has to pull data from third party APIs..

ISY will send data to a nodeserver if you use a program to send it there but it does not send data on its own. Nodeservers are much like third party apps that send and pull info from ISY.

The fastest way to get data to the nodeserver is to push it from ISY with a program otherwise ISY has no idea that it needs to send data to the nodeserver.

[MWareman]

I suspect you could establish a websocket subscription to ISY and this would eliminate polling. This is what I thought the Polyglot library does on behalf of running polys.

[mwester]

No, neither the polyglot framework nor individual node servers are aware of everything the ISY does (i.e. the websocket thing) -- in fact, it's quite the opposite -- the ONLY thing that Polyglot-the-framework knows about are the events about the nodes (administrative activities) and the specific commands that are sent to the node servers by the ISY.  These commands are explicit requests for data or explicit commands to the node server -- with no information outside of that node server's set of commands or values.

(In fact, for this node server, since there's no means in the Node Server API, I suspect that the author has had to use the general ISY REST API to "go around" Polyglot-the-framework in order to access variables.  The Node Server API is, by design, extremely limited -- it's designed so that a node server could work as a "device driver" for some other HA system, not just the ISY...)

[markv58]

@mwester Thank you for that detailed answer! I am in fact using the ISY REST API to get around the limitations. I am a fabricator by trade and as such, if something isn't doing what I want it to do, I just grab a bigger hammer out of a drawer and convince it. Doesn't work quite the same in programing.