jkosharek Posted February 22, 2022 Posted February 22, 2022 Part of my sleep timer program for my bedroom TV is turn on Sonos 'Speech Enhancement' and 'Night Mode' via a network resource to other node server (https://github.com/jishi/node-sonos-http-api). I would be willing to contribute to getting those functions added to the PGv3 Sonos Node! 1
jkosharek Posted February 22, 2022 Author Posted February 22, 2022 The Sonos PG3 version doesn't have a parent node. All nodes should have a parent node for status. I have program alerts set for all of my nodes, so if they go offline I get a notification. Michel Kohanim is there any requirement for nodes to have a parent or node status?
bpwwer Posted February 22, 2022 Posted February 22, 2022 1 hour ago, jkosharek said: The Sonos PG3 version doesn't have a parent node. All nodes should have a parent node for status. I have program alerts set for all of my nodes, so if they go offline I get a notification. Michel Kohanim is there any requirement for nodes to have a parent or node status? Node servers are not required to have a node dedicated to providing node server status. Nor are node servers required to report node server status to the ISY. Node server status (as it has been typically done) doesn't even really make sense with PG3. If the node server dies or crashes, there isn't a running node server to report that fact. PG3 will only change the status if someone actually presses the button to start/stop the node server so if you're changing the status, you shouldn't need a notification to tell you that you changed the status. It is possible for a node server to configure PG3 to send connection status to one of it's node values. However, that is only tracking the connection status between the node server and PG3. It is possible (and probably likely) that a node server can fail while still remaining connected to PG3. 1
jkosharek Posted February 23, 2022 Author Posted February 23, 2022 42 minutes ago, bpwwer said: Node servers are not required to have a node dedicated to providing node server status. Nor are node servers required to report node server status to the ISY. Node server status (as it has been typically done) doesn't even really make sense with PG3. If the node server dies or crashes, there isn't a running node server to report that fact. PG3 will only change the status if someone actually presses the button to start/stop the node server so if you're changing the status, you shouldn't need a notification to tell you that you changed the status. It is possible for a node server to configure PG3 to send connection status to one of it's node values. However, that is only tracking the connection status between the node server and PG3. It is possible (and probably likely) that a node server can fail while still remaining connected to PG3. That seems like a step backwards in PG3 to not have a mechanism as it is in PG2? This morning I work up to an alert for my HUE node (ISY Program configured to email when the node was not connected), so I looked at PG2 and needed to start the HUE node. Are you saying that wouldn't work if/when HUE gets migrated to PG3?
bpwwer Posted February 23, 2022 Posted February 23, 2022 I'm not saying that nothing will work. It depends on the node server design and what the node server author does with it. But because node servers are multi-threaded, it is very possible that one thread will crash while the thread that has the connection to PG3 continues and you'll never know that the node server isn't working. What we need is for something to independently monitor the process and report back to the ISY when a node server is not functioning, but the ISY doesn't have anyway to handle that yet.
lilyoyo1 Posted February 23, 2022 Posted February 23, 2022 12 hours ago, jkosharek said: That seems like a step backwards in PG3 to not have a mechanism as it is in PG2? This morning I work up to an alert for my HUE node (ISY Program configured to email when the node was not connected), so I looked at PG2 and needed to start the HUE node. Are you saying that wouldn't work if/when HUE gets migrated to PG3? Nodeservers are designed by different developers so what one chooses to do with theirs may not be the same way for another. I've experienced what bpwwer with my ecobee and harmony nodeservers so I get his point.
Michel Kohanim Posted February 23, 2022 Posted February 23, 2022 I think this should be a hard requirement: all node servers must report heartbeat. With kind regards, Michel 2
bpwwer Posted February 23, 2022 Posted February 23, 2022 53 minutes ago, Michel Kohanim said: I think this should be a hard requirement: all node servers must report heartbeat. With kind regards, Michel Then the ISY needs a way to accept a heartbeat.
Michel Kohanim Posted February 24, 2022 Posted February 24, 2022 @bpwwer, is that any different than adding a ST property for a Heartbeat node? With kind regards, Michel
Jimbo.Automates Posted February 24, 2022 Posted February 24, 2022 Essentially that's what I use controller for. Send DON/DOF for heartbeat. I didn't want the extra overhead of yet another node just for heartbeat, but we could if that's what we agree to. Or we had a special command like HBT that would probably be better?
bpwwer Posted February 24, 2022 Posted February 24, 2022 4 hours ago, Michel Kohanim said: @bpwwer, is that any different than adding a ST property for a Heartbeat node? With kind regards, Michel If you want to make it a hard requirement, then yes. This is mostly just my opinion, but it seems like nodes are a representation of a device. If the device supports a heartbeat, then the node can also. Having a node represent the node server itself doesn't seem right to me. In general the node server should be invisible. In support of this, I look at how Insteon and z-wave are implemented and neither of those have "control" nodes that represent the controllers. I think of a node server as similar to a PLM or z-wave dongle just implemented in software vs. hardware. I know this isn't a perfect analogy but it seems pretty close. I know a node can represent anything and if we really want to create nodes that represent the node servers, then I think it should have a standard node definition and standardized driver types/command types and UOM's that are designed to represent that. One of the reasons I've been hesitant to create nodes for my node servers is because of nodes being a limited resource and using one just to report the status of my node server seemed like a waste of that resource. If this is no longer the case with IoP then I'm less opposed to these types of nodes.
Michel Kohanim Posted February 25, 2022 Posted February 25, 2022 @bpwwer, I totally agree with you. We do not have any resource constraints on Polisy. And, once we get rid of that monster, mongodb, we'll gain back another 800MB. This said, and based on your explanation, I am not so sure. Perhaps we can ask @Chris Jahn. With kind regards, Michel
bpwwer Posted February 26, 2022 Posted February 26, 2022 1 hour ago, Michel Kohanim said: @bpwwer, I totally agree with you. We do not have any resource constraints on Polisy. And, once we get rid of that monster, mongodb, we'll gain back another 800MB. This said, and based on your explanation, I am not so sure. Perhaps we can ask @Chris Jahn. With kind regards, Michel This is maybe not the best place to discuss some of this. I've some similar discussions over slack. If we want to create nodes that represent the node servers, I think we should make that mandatory and provide a well defined definition that lists what is required of those nodes. Today we have a mix of things. Some node servers have a node just for node server status, some mix the status in with the device nodes, some don't report status at all. In many cases, I've moved to not reporting status at all because what we have as node server status today isn't as useful as many think. It really only tracks the mqtt connection between the node server and PG3 (which is it's own thread in the node server) so everything else in the node server could be failing and your connection status would still be good.
Recommended Posts