A Plugins node indicating that its logged in, or not

[paulbates]

I have a yolink outlet that I use to monitor the power consumption of my second floor dryer, and manage the room exhaust fan when the dryer  is in use. It's always worked before, but today I turned the dryer on, and nada. Tried it twice, no go.

When I looked at pg3x for the yolink plugin, there were repeating messages that made me believe it wasn't logging in to yolinks servers and there were no device messages. (When I restarted the plugin, I lost the exact messages). There was an update available for the plugin, I updated and normal log messages started flowing by and the dryer room fan worked again.

I don't know if

1. this is a feature request,
2. there's a way to do it and I don't know....
3. or if each plugin author of a plugin that needs authentication to a service....

but here goes:

Feature request:  I would like a node for each of my networked plugins that is true when it's connected to its products' networked service and false when it's not. It's up to me to write iox programs that deal with that info. (I'd leave a 5 - 10 minute wait as services/plugins do go up and down, briefly and occasionally). The point is, I would like to send a notification, so I don't wait until I stumble across it.

This also happened with the ring plugin earlier this year. I did see the forum posts on it.

If the answer is the plugin authors need to do it, I'll ask them individually.

[Goose66]

This is a design decision made by each plugin author. IMHO, the right answer is for each plugin to report statuses (running, connected to cloud service, authenticated, stopped, failed, etc.) that are common across most plugins and have this displayed and managed in the Admin Console, e.g. under the Plugins menu. Unfortunately this require a rework of the Plugin interface - preferably by ripping out the old Node Server REST API layer and linking the plugins directly to IoX via MQTT (a layer that already exists).

The nodes are supposed to represent devices.

[paulbates]

Thanks @Goose66. Not surprised at that answer. 

I'm going off the distant memory of nodelink, It had a heartbeat feature and I think with Venstar it could detect when it lost touch with skyport cloud.

To make sure I got it, you're saying

1. a plugin author could do what I'm asking, if they chose to, without the major plugin interface rewrite?
2. or...doing it all would be a major plugin interface re-write?

[bpwwer]

Some do it already, but the how is not standardized so how it works for each plug-in is going to be different.

In my case, I have a number of plug-ins that don't need any type of control interface so each node represents a device (say a light switch or networked bulb).  For those types of plug-in's I'd have a new node that does nothing but report the interface status or add the interface status to each node.  I don't find either design compelling, plus it would be a bit more than a minor change.

Even with plug-ins that have a controller type node, there's no standardized way to report that.  The logical choice would be to report it as the node's status, but that is typically used now to report the status plugin, not it external interface.

You're probably thinking it's just a couple of plugins that need this, but there's something like 188 plugins the store and some of those are no longer being actively maintained.  So it's a pretty major effort for everyone to do this.  I know I have very little time right now to do major plug-in development, I'm struggling just to bugfix/updates when needed.

I proposed something similar to what @Goose66 wrote above while we were doing PG3 development, but it would take a bit of effort to the develop the IoX side and other issues were a much higher priority.

I agree that this would be the right direction, but with so many plugins having to be changed the existing methods would have to remain in place and the conversion could take quite a while. That's assuming UDI has the resources available to do the IoX side of the implementation.

[Goose66]

Many of the plugins have what you are asking. The plugins I have developed that use cloud services (iAquaLink, Schlage, MyQ, Nest, ipool) should all have a node that represents the cloud service connection with connection status. Others have done the same.

Edited August 6 by Goose66

[paulbates]

Thanks @Goose66 & @bpwwer

Bob, for the ecobee plugin, there's a field for the main ecobee controller node labeled "Authorized", which can be true of false. I take it that's the way to do what I want in that particular case? If there's a problem on ecobee side, and the plugin detects its not connected/logged in, that gets flipped to false?

[Goose66]

I think ecobee is a @Jimbo.Automates plugin.

Edited August 7 by Goose66

[Jimbo.Automates]

I think ecobee is a @Jimbo.Automates plugin.

Yes, ecobee knows if the API authorization succeeded.

Sent from my Pixel 8 Pro using Tapatalk

[apostolakisl]

I have had plenty of instances where a node looks good, but doesn't function. Reboots typically fix it. Just yesterday I had to reboot blue iris node. Blue iris said connected, but wasn't. The heartbeat system in nodelink never fails me. I actually went through some hoops to get nodelink back because it was so stable. 

[Jimbo.Automates]

I build heartbeat into all my plugins which is used to confirm the plugin is still functional and connected to polyglot and polyglot connection to IoX is good. That is different from API authorization which can fail but heartbeat is still good.

Sent from my Pixel 8 Pro using Tapatalk

[paulbates]

3 hours ago, Jimbo.Automates said:

build heartbeat into all my plugins which is used to confirm the plugin is still functional and connected to polyglot and polyglot connection to IoX is good.

Yes and I use that for your's and other's plugins and they do go off every once in a long white.

The problem I was having with a plugin (not your's) was that there was no pg3x to iox errors and it still did not function as expected. So I'm adding a layer of error checking to give notice of plugin login failure.

Edited August 9 by paulbates