search

windkh / node-red-contrib-shelly

Shelly control nodes for node red.
MIT License
34 stars 21 forks source link

Feature request: a tickbox for "off-grid mode - no offline errors" would be nice? #180

Open houser42 opened 1 month ago

houser42 commented 1 month ago

Hello,

Happy user here, using this great node in off-grid installs. I have a request that is more about keeping things tidy than anything else. I routinely use Shelly devices with this node in installs, where the AC power is switched off daily while retaining DC power and of course this node then spits out errors like this: "Error in executeCommand1: /status --> Error: connect EHOSTUNREACH 192.168.xx.xx:80" This makes the log hard to read. If it would be possible to add a tickbox for "off-grid mode - no offline errors" I would be nice. Or if there is any other clever workaround.

windkh commented 1 month ago

@houser42 hm .... do you know when you are running on DC in node-red. I mean polling could be turned off completely during DC mode.

houser42 commented 1 month ago

Yes, I am referring to planned automated AC shutdowns where the DC power stays on. I looked through the Shelly API if it would be possible to shut off polling with an injected payload but found nothing. Would your node accept and respond to such a payload if there is one?

While we are on polling house keeping. The Shelly H&T:s that runs on DC USB power sends this string much of the time regardless:

"Error in executeCommand1: /status --> Error: connect EHOSTUNREACH 192.168.xx.xx:80"

It works and sends data but spends much of the time complaining about connectivity even if it does send the data as it should. I assume it is designed to conserve power, use MQTT and does not understand that it has constant power. Do you have any tricks for that?

windkh commented 1 month ago

I will implement a command that can be injected so that polling can ba paused...

About the H&T. For that reason I always operate these low-power sensors only in callback mode. Most of the time the device is sleeping and a pollrequest just ends in a timeout. As far as I know you can not configure that behavior, but maybe it changed in the meantime... I will have a look

houser42 commented 1 month ago

Sounds good, appreciate the constructive feedback! A way to switch off polling would be very useful for this scenario.

I have never used callback or the "Shelly server" but it seems to work. Do you have a port recomendation? Same for all nodes/devices? I assume this server is instantiated on each Shelly device? Or is it done in your node?

windkh commented 1 month ago

I use port 10000, anyone above around 10000 should be fine. One server for all gen2 devices and another one for all gen1 devices is enough... so no waste of resources. A simple script is installed in the shelly to issue the callback on every event. You can also forward blutooth messages.

houser42 commented 1 month ago

Short follow-up on the H&T: I was trying to get the temp and humidity payloads directly from the node, rather than MQTT, and not seeing it. Ss that in there or am I missing something? Thanks.

windkh commented 1 month ago

What do you mean with "directly"? If you inject a message into the node to get the status while the H&T is sleeping you won't get a response as you can not wake it up using a message.

houser42 commented 1 month ago

Sorry to be unclear. By "directly" I meant from the node rather than MQTT which is what the system I am working on now is set up to use. I see no temp or humidity payloads coming from the node itself. Should I?

Edit: I see it now. The node was incorrectly set to "event" rather than "status". All works now. Apologies!

windkh commented 1 month ago

@houser42 let me know if the callback solution worked for you

houser42 commented 1 month ago

Yes, the callback works well. Should have confirmed. Apologies.

windkh commented 1 month ago

@houser42 ah fine... so is it then necessary to implement your requested feature for polling mode or not, what do you think?

houser42 commented 1 month ago

Ok. The requested feature is mainly for Shelly AC accessories that start sending error messages when AC is off. The callback feature I set was for a H&T device that is only on DC. Are you saying we should use callback for AC devices generally? I like the way it works with polling when AC is available. It is very responsive. Am I making sense? I guess this could be something one sets in the GUI and not something that is switched off by a payload. I guess we could switch is on when we need more feedback for troubleshooting

windkh commented 1 month ago

Ok