Local control settings clarifications

[mosaicws]

First off, thanks for sharing such a great Node Red addon. I've mostly set it up but now want to get local control working.

I'm running Node Red in a Docker container and since docs say only UDP will work (I do have another container running avahi with network mode:host but maybe that wont work?) I need to set the Broadcast address.

Docs say:

For UDP, fill in the fields as follows, Broadcast address: The IP range of your local network, e.g. 192.168.178.255.

So my router provides a network starting 192.168.0.1 and hands out addresses like 192.168.0.10 etc so I've set my Broadcast address to 192.168.0.255. Is this correct?

Also I have these settings for my Node red container now:

    ports:
      - "1880:1880"
      - "3121:3121/tcp" # TCP port for local execution
      - "3121:3121/udp" # UDP port for local execution

In the Management node, I've set Discovery port to 3121 and HTTP to 3121 - is this correct? Can they be the same port? (probably not!). In the docs example it only shows 8882 being forwarded?

In your example you say "you must explicitly forward the listen and broadcast ports for TCP and UDP" but does this apply if the ports are different? I originally set the Discovery port to 3121 and HTTP to 3122 - would this mean I need to forward both ports in the Docker container like this?:

    ports:
      - "1880:1880"
      - "3121:3121/tcp" # TCP port for local execution
      - "3121:3121/udp" # UDP port for local execution
      - "3122:3122/tcp" # TCP port for local execution
      - "3122:3122/udp" # UDP port for local execution

Thanks again for all your work on this and sharing it! Hope it continues to be developed.

Edit: I'm seeing "msg: "Error in HttpActions:reportState()"" in a debug node for a Device node and and ""HttpActions:requestSync(): skipped requested sync, http server is not running"" for the Management node that otherwise seems to work ok. Could this be due to misconfiguration?

Edit2: I set "Force local" and then a voice command to turn on a light (sending a message to zigbee2mqtt) and it worked (indicating local fulfilment is actually working?!) although the icon in Node Red wasn't a ring icon as described in the docs?

Also - is there any way to sync the light status? i.e. when I turn the light on manually using the switch, this is reflected in the Node red flow and in the Google Home app? Or would this need to be done manually in a flow sending a message back to the Light device node from mqtt?

[Caprico85]

Hi @mosaicws

So my router provides a network starting 192.168.0.1 and hands out addresses like 192.168.0.10 etc so I've set my Broadcast address to 192.168.0.255. Is this correct?

This is correct. Broadcast 192.168.0.255 reaches all addresses in 192.168.0.*. Broadcast 192.168.255.255 reaches all addresses in 192.168.*.*. So 192.168.255.255 would work too.

In the Management node, I've set Discovery port to 3121 and HTTP to 3121 - is this correct? Can they be the same port? (probably not!).

This is correct. Discovery and HTTP ports can be the same port. Discovery port uses UDP, HTTP port uses HTTP, so they won't conflict with each other. I changed the docs to explain this a bit better.

In the docs example it only shows 8882 being forwarded?

The docs use 8882 as both discovery and HTTP port. That's why it only shows 8882 as both tcp and udp.

In your example you say "you must explicitly forward the listen and broadcast ports for TCP and UDP" but does this apply if the ports are different? I originally set the Discovery port to 3121 and HTTP to 3122 - would this mean I need to forward both ports in the Docker container like this?

If you use different ports, the discovery port only has to be listed with udp and the HTTP port with tcp. So it would be:

 ports:
      - "1880:1880"
      - "3121:3121/udp" # Discovery port for local execution
      - "3122:3122/tcp" # HTTP port for local execution

I'll answer the remaining questions later.

[Caprico85]

Also - is there any way to sync the light status? i.e. when I turn the light on manually using the switch, this is reflected in the Node red flow and in the Google Home app? Or would this need to be done manually in a flow sending a message back to the Light device node from mqtt?

You currently only have the output side of you Google node connected, like this (with zigbee2mqtt instead of Tasmota)?

Then Node-RED and Google have no way of knowing the current state of your device. You need to send external state changes back into the Google.

You usually have to build some kind of loop to forward changes from Google to your physical device and changes from your device back to Google.

The "Basic usage" section in the setup guide explains this further.

[Caprico85]

I set "Force local" and then a voice command to turn on a light (sending a message to zigbee2mqtt) and it worked (indicating local fulfilment is actually working?!) although the icon in Node Red wasn't a ring icon as described in the docs?

If the command works with "Force local", it means it really was executed with local fulfillment ... or Google broke their local fulfillment stuff once again.

To be sure, enable debug output on your management node, control your device and check the debug log. If it was executed locally, you'll see the line user: local execution. If not, you'll see some other username.

2024-08-01T19:58:57.541622911Z HttpActions:httpActionsRegister(/smarthome): user: local execution
2024-08-01T19:58:57.541799372Z HttpActions:httpActionsRegister(/smarthome): EXECUTE
2024-08-01T19:58:57.541953073Z HttpActions:_exec()

You can also check the output from the app.js script. Open Google Chrome and go to the URL chrome://inspect. After a while you should see your smart speaker. Click on the Inspect link, Then switch to the Console tab. If the local fulfillment connection was established, you'll regularly see REACHABLE_DEVICES messages.

If you control your device, you should also see EXEC messages if it is executed locally.

[Caprico85]

Regarding the ring icon:

Do you use the latest version of our module? We had a bug some versions ago that prevented the ring icon from showing.

It's also possible that the ring icon is immediately overridden if you have this "loop" structure.

A command is executed locally and the icon changes to the ring. But the Tasmota node detects a state change, sends a new message and overrides the icon with the normal icon. This takes a few milliseconds, so it is usually too fast to notice that the ring icon was actually there.

[mosaicws]

@Caprico85 Thanks for all the replies and information, really useful clarifications which have helped a lot and for simplicity I've ended up just using the port mentioned in the docs, 8882. (I only used 3121 and 3122 instead as my usual practice of "randomising" ports from expected ones but no need here).

I did experiment out of curiosity (against the docs advice sorry!) with seeing if my avahi container would work and provide local control via mDNS and maybe it did (as mentioned I used "force local" which seemed to work) but I've now switched back to UDP settings and I'm seeing the ring icon instead of circle which shows local is working:

I'll do some further testing to familiarise myself with all the Device node settings (you've added very comprehensive functionality already) but all looking great so far!

My goal was to be able to get Google Home working with Node Red so that I don't have to use Home Assistant almost only for its Google Home integration which was a bit flaky and possibly abandoned (I use Node Red for all my automations anyway). With these nodes looks like i'm much close to being able to do that.

Next step for me is implementing the updates to Google Home from device state changes using the examples you've shown. I think the Home Assistant Google Home intrgration did this automatically somehow but it was always a bit laggy (I've developed on Google platforms before (Google Apps script) and there are always quirks and unexpected limitations)).

Thanks again and looking forward to future updates! :-)

EDIT: One thing, I'm not seeing any messages like this:

2024-08-01T19:58:57.541622911Z HttpActions:httpActionsRegister(/smarthome): user: local execution 2024-08-01T19:58:57.541799372Z HttpActions:httpActionsRegister(/smarthome): EXECUTE 2024-08-01T19:58:57.541953073Z HttpActions:_exec()

in the Management Node debug. Node Debug for the Management node is definitely turned on but all it outputs when i turn on or off the light is:

{"_type":"server","state":"start","param1":3002}

Not necessarily an issue as local does seem to be working, just letting you know. I am however seeing this:

"HttpActions:requestSync(): skipped requested sync, http server is not running" - i guess thats not an error and just a message due to the brief time the server isn't running when I redeploy the flow?

[Caprico85]

in the Management Node debug. Node Debug for the Management node is definitely turned on but all it outputs when i turn on or off the light is: ...

That's strange. You enabled node debug on the config? And you're looking at Node-RED's log file (docker log <container> if not configured otherwise)?

"HttpActions:requestSync(): skipped requested sync, http server is not running" - i guess thats not an error and just a message due to the brief time the server isn't running when I redeploy the flow?

I'm not sure if this is to be expected. I wanted to check if my requestSync() does the same. But now I'm seeing that I got a different problem with syncing ("ERR_OSSL_UNSUPPORTED"). I'll report back when I got it working and was able to check.

To rule out possible other reasons you could try:

• Check if syncing works at all by saying "Hey Google, sync my devices".
• Connect an Inject node to your management node and set it to send msg.topic = request_sync. Then, when everything is running, send the message. This should show us if the problem only occurs on startup or also during runtime.
• Check that you have only one single config node. That is, in your management node there is only single config listed in the "SmartHome" select box. If there are other configs, even if unused, they can try starting up and leading to errors messages.

[mosaicws]

That's strange. You enabled node debug on the config? And you're looking at Node-RED's log file (docker log <container> if not configured otherwise)?

Yes I enabled the debug on the config, I've been looking at the output of a debug node in Node Red but I think the error message isn't coming from the Device debug node i manually attached but instead from the Management Node with Node Debug enabled.

• Check if syncing works at all by saying "Hey Google, sync my devices".
• Connect an Inject node to your management node and set it to send msg.topic = request_sync. Then, when everything is running, send the message. This should show us if the problem only occurs on startup or also during runtime.
• Check that you have only one single config node. That is, in your management node there is only single config listed in the "SmartHome" select box. If there are other configs, even if unused, they can try starting up and leading to errors messages.

So at this point, I think I've got everything working as expected. I do keep seeing "HttpActions:requestSync(): skipped requested sync, http server is not running" in the output of what I now think is the Device "Light Node" which happens when I click "Deploy" in Node Red and I'd guess is due to a brief period where the Device node cannot access the Http server while it's starting up again after a Node Red deploy. Not really an issue I think but I suppose could be addressed by a slight delay after Deploy.

I started a Discussion here so as not to clog up the Issues section. I figured out that when a device appears in the Google Home app (on my phone) in the "Linked to you" section at the very bottom of the Devices page, it won't sync state with any manual updates to a device. So if I turn on a Device node. i.e. "Light Node" in my screenshot using an inject node, this doesn't update in the Google Home app unless I refresh.

For a Device node to automatically sync state with the Google Home app (and I guess Google's servers) it appears it must be added to a Home and possibly to a Room also in the Google Home app. Then it syncs state after a second or two automatically, as expected. Might be worth adding this to the docs to help others who could have the same issue. During testing I didn't want to add a test device to a room because Google makes it difficult to remove a device from a room other than moving to another room.

Thanks for your help with this. I'd say at this stage problem solved and thanks again for making these Nodes available!