Enhanced Maximum Uptime Discussion

[randy]

One observation after about 28 minutes the current uptime stopped updating. After 10 minutes still no update. Log entries attached.



EDIT: I noticed that the device does not have a technology address and that there is another set of HS Log entries under the type MaximumUpTime (in addition to MaxUpTime) they are also attached.

[randy]

Since the technology address was missing from about the time I edited the devices to change the graphics, I started over. I disabled the recurring event, deleted the devices and shut down HS. Then I edited the config file again, this time editing the references to images to add my own. Then I restarted HS. Now the images are correct and the address is there.



I have no idea why the address would have been cleared by editing the status graphics images, but now it is all correct.

[randy]

OK, it all looks correct. Here are the devices created and updating correctly along with the images I chose.



Also attached are the log entries and the config file.

[randy]

I restarted HS after about an hour and here are the devices. It doesn't seem like the previous uptime and maximum no fault uptime are correct.



I'll let it run for a few hours and try again. Log from 9:00AM attached.

[Wadenut]

One observation after about 28 minutes the current uptime stopped updating. After 10 minutes still no update. Log entries attached.

[ATTACH]60558[/ATTACH]

EDIT: I noticed that the device does not have a technology address and that there is another set of HS Log entries under the type MaximumUpTime (in addition to MaxUpTime) they are also attached.

That second log is a running history of runtimes. If you don't need it, you can turn it off. EnableHistLog = False

[Wadenut]

Since the technology address was missing from about the time I edited the devices to change the graphics, I started over.

I have no idea why the address would have been cleared by editing the status graphics images

It's HS3.
The only time the script modifies a device (other than setting the device string) is on startup when, if a device (code) is missing, it's recreated. It looks for the device code, not the reference or address. I had to do this to maintain compatibility with HS2 for which this was originally written. I noted earlier, that the two versions of the script are identical in every respect, except foe a small portion (common to all of my HS2/HS3 scripts) which deals directly with the functional differences between the two, or future, versions. This way. I can make logical changes to one copy (usually HS3 where I test), then paste the main code into the other.

That said, I just tried the same thing, with the same result. Unfortunately, this is out of my control. You ought to be able to simply re-edit the device, replacing the tech address (DC).

but now it is all correct.

We'll get there

[Wadenut]

The only other thing I can think of is that something has drastically changed in later versions of HS3. I'm on a much earlier version (208), and hadn't upgraded in some time as that machine hasn't been used in over a year, until recently, and as it's a test machine has nothing external attached to it.
Once I get things settled down here (other work), I'll go ahead and install the latest version.

Still puzzled however because the only thing the script does in operation is write device strings to the devices. All of the devices were created identically, and are all treated identically; but you seem to have some updating, but others not, which is why I'm so confused.

[randy]

The only other thing I can think of is that something has drastically changed in later versions of HS3. I'm on a much earlier version (208), and hadn't upgraded in some time as that machine hasn't been used in over a year, until recently, and as it's a test machine has nothing external attached to it.
Once I get things settled down here (other work), I'll go ahead and install the latest version.

Still puzzled however because the only thing the script does in operation is write device strings to the devices. All of the devices were created identically, and are all treated identically; but you seem to have some updating, but others not, which is why I'm so confused.

After the last reset, they *seem* to be working. Let me keep testing to see if I identify a repeatable problem. I am doing some reconfiguration of hardware that requires restarts, moves and restores. When I get it all settled I will start the timers over and see what is happening.

[Wadenut]

After the last reset, they *seem* to be working. Let me keep testing to see if I identify a repeatable problem. I am doing some reconfiguration of hardware that requires restarts, moves and restores. When I get it all settled I will start the timers over and see what is happening.

Well, let's hope so.
Attempting to upgrade HS3 here failed miserably and now as far as that goes I'm completely dead in the water.

[Wadenut]

Managed to re-install HS3 (v318) on a different machine then copied the entire folder back to the test machine.
I've noticed some very odd, if not disturbing behaviour compared to the previous version (208). It may simply be a result of Windows update, but yet to be determined.

The "Short Time" version should be available quite soon.

[bdraper]

I experienced some very strange issues as well during a recent upgrade. I upgraded from 3.0.0.218 to 3.0.0.298. See this post for more details, https://board.homeseer.com/showthread.php?t=187161

I eventually landed on version 3.0.0.307 and have been running it ever since with no issues.

Good luck on your upgrade Greg.

[Wadenut]

At least it's not only my experience. I'm seriously thinking of reverting HS3 back to 208 from a backup, as all of my HS2/HS3 compatible packages only deal with device strings and values. I have no external hardware installed on the HS3 machine and thus only a minimum number of plugins. So far, 318 hasn't run for me more than about 30 minutes at a time before becoming unresponsive.
I was hoping to be able to put all this away for the summer by now, but it looks like this weekend is going to be shot.

Biggest problem now is that after attempting to install 318, which failed, now, every version of HS3 I've tried to install directly, fails saying "The installer is not valid". Uninstalling, also fails. I have to install on another machine and copy the HS3 folder to the test machine. NOT Impressed.

[Wadenut]

Is it possible to change the format of the device strings? For instance, trying to conserve space on HSTouch and it would be preferable to use the standard format of 1d 01:01:01 or even 1d 1h 1m 1s.

This is completed. Posted as v2.12.5 this morning.
- [Easy path to upgrade] Just replace the VBEN script, and add ShortTime = True to your config to upgrade. Instructions in the doc to have all devices converted immediately, otherwise they will convert when each updates.

[Wadenut]

This, with V2.13.1, has undergone a major rewrite resulting in a smaller file, improved reliability of the retention of data, and FIVE additional selectable devices to track HS system performance.

- Now works with HS3, HS3 including Pi versions.
- All devices except "Current Run Time" are optional.
- NEW Down Time measurements devices are available.
- Colour coded Device String text. Colours are definable to suit users preferences.
- Optional graphics are assigned to the device rather than included in Device Strings in HS3 versions.
- The initialization entry in the Startup.vb/Startup.txt script is now optional and can be omitted.

[Wadenut]

About the time I posted this, HS4 Pre-Beta went online and presents me with a couple of it's own issues. Nothing serious, but colored text won't work as things stand right now. I've reported this as a minor bug. I have another optional method to indicate status and I'm just working to ensure the changes work on all versions of HS to avoid having to maintain three versions of this package. Hopefully, It'll be ready within the week. Meantime, the posted version will work with HS4, just no bells and whistles.