[HS4] ET Global Variables - Parent device name? ... ID broken without it

[Ltek]

spud I looked in the user guide and searched a ton, did not find the answer.

Just switched to HS4 and now the variables I was using for scripts and notifications no longer report the needed info as its now only pulling Child devices, which do not have unique identifying text.

Have you updated the ET plugin (or will you be soon) to pull in the Parent device name also? Otherwise we don't know what actual device was changed.

Example using attached screenshots. using the below variables...

$$GLOBALVAR:ETDeviceLocation1_GarageDoors:
$$GLOBALVAR:ETDeviceName_GarageDoors:

HS3 results... "HSMyQ Garage 1 Door Sensor"
**perfectly shows needed ID info

HS4 results... "HSMyQ Door Status"
** does not show enough identifying data without Parent info - would never know which 2 doors caused it. Exacerbated with sensors like door/window/motion/temperature where there could be 8, 10, 12 or more identical devices

[kenm]

On the ET Config page, check the setting for "Device name format". spud added this a while back when I pointed it out to him.

I'm not sure if it will fix the problem you are seeing but worth a shot.

[Ltek]

On the ET Config page, check the setting for "Device name format". spud added this a while back when I pointed it out to him.

I'm not sure if it will fix the problem you are seeing but worth a shot.

I already had this set... I changed it, exited the Plugin screen, went back and reset to the attached screenshot. Does not work - Parent name is not being added to the variable.

spud, this is a fresh HS4 over the top of HS3

this... $$GLOBALVAR:ETDeviceLocation1_GarageDoors: $$GLOBALVAR:ETDeviceName_GarageDoors: $$GLOBALVAR:ETDeviceStatus_GarageDoors:

results in... HSMyQ Door Status Closed

it should be... HSMyQ Garage 1 Door Status Closed

[kenm]

Unfortunately, this is an area where HS3 Legacy plugins start to show their age. This is going to become very obvious when HST moves to .Net Core 6.0 and every legacy plugin stops working unless it's recompiled.

[Ltek]

Unfortunately, this is an area where HS3 Legacy plugins start to show their age. This is going to become very obvious when HST moves to .Net Core 6.0 and every legacy plugin stops working unless it's recompiled.

Dont blame the plugin coders, blame Rich. Without all the plugins, HS is nearly useless. Rich should (do a lot of things he won't or maybe doesnt know how) ensure the plugins don't break. Especially ones like EasyTrigger which is 100x more functional than anything Rich ever built for Events.

spud please let use know if you will fix this. thanks for the help!

[spud]

I thought I had addressed this when I added the "Device Name Format" setting. What version of EasyTrigger are you running?
I will have a look at this on monday.

[Ltek]

I thought I had addressed this when I added the "Device Name Format" setting. What version of EasyTrigger are you running?
I will have a look at this on monday.

3.0.0.75 ... Used it on HS3 also. I just moved to HS4 3 days ago.

[spud]

I had this coded but never released it, it's done now, please install and test beta version 3.0.0.76

[avpman]

Unfortunately, this is an area where HS3 Legacy plugins start to show their age. This is going to become very obvious when HST moves to .Net Core 6.0 and every legacy plugin stops working unless it's recompiled.

What?!?! I hope they provide a concurrent method that would still run the legacy plugins for which they do not have the source code. IMHO, plugin authors should be required to escrow their code at HS in cases where the author disappears, but we still depend on the plugin.

[jon00]

IMHO, plugin authors should be required to escrow their code at HS in cases where the author disappears, but we still depend on the plugin.

Ha Ha... you clearly have no idea how much it costs to escrow software! No plugins would ever be written by 3rd parties!

[avpman]

Ha Ha... you clearly have no idea how much it costs to escrow software! No plugins would ever be written by 3rd parties!

There needs to be some solution. Otherwise we're just depending on something that might not be supported. Every time I add a new plugin, I'm taking a risk by depending on it.

[jon00]

There needs to be some solution. Otherwise we're just depending on something that might not be supported. Every time I add a new plugin, I'm taking a risk by depending on it.

But that's the same with all software you purchase?

I purchased HS1 & HS2 & HS3 but none are supported now?

[Ltek]

spud THANK YOU... that works. Without you, Jon00, Wim, and others -- well, you know!

There needs to be some solution. Otherwise we're just depending on something that might not be supported. Every time I add a new plugin, I'm taking a risk by depending on it.

... way OT but... I started a thread on this years ago when several top notch PI and script coders left. Escrow is not answer due to the formalities/cost BUT simply having a contract agreement with HST that upon a given time period without updates/bug fixes, and keeping up with HS version changes, the code would be released as freeware/open source -or- HST would be obligated to maintain it for free and provide to users. That brings up the obvious question... something happens to Rich, HS goes EOL. He should have a escrow commitment to Open Source the code if the company ever shuts down, for any reason. I'm sure he would not even entertain that conversation because, as we know he's all about his customers!

[avpman]

spud THANK YOU... that works. Without you, Jon00, Wim, and others -- well, you know!




... way OT but... I started a thread on this years ago when several top notch PI and script coders left. Escrow is not answer due to the formalities/cost BUT simply having a contract agreement with HST that upon a given time period without updates/bug fixes, and keeping up with HS version changes, the code would be released as freeware/open source -or- HST would be obligated to maintain it for free and provide to users. That brings up the obvious question... something happens to Rich, HS goes EOL. He should have a escrow commitment to Open Source the code if the company ever shuts down, for any reason. I'm sure he would not even entertain that conversation because, as we know he's all about his customers!

A contract option is great but only viable if the PL author is around to honor their commitment. A few PL authors have already posted their code on git after they elected not to maintain it. At the very least, maybe HS should ask the authors if they would do the same and add that yes/no to the sales info for the plugin. I know that's not a guarantee, but again, something needs to be done.

[Ltek]

spud one more, small ask... can you add the format option : <room> <Parent> <feature>?

For me, and I think many others, Floor is used more for organizing devices (like "Plugin" for plug-ins) in the list vs as a unique identifier. But when used as an actual floor (Basement, Main level, etc) most will still not need it in a notification or such because most rooms will only be on a single floor - like, Living Room is likely on only one floor. Bathroom might be the exception ;-)

For HS4 plugin update (if you are still planning one?) I suspect you'll separate out Parent and Category?