[Bug]: Service re-uses last received topic value about node-red-contrib-homekit-bridged HOT 3 CLOSED

@crxporter, indeed looks like we are storing topic and sending it later.

1. Can you replicate?
2. Is that a bug?

onInput
node.topic_in = msg.topic ? msg.topic : ''

onValueChange
const topic = node.config.topic ? node.config.topic : node.topic_in

from node-red-contrib-homekit-bridged.

Topic is always an interesting topic to discuss... see what I did there?

Anyway, what would the expected behavior be? I would expect:

For a pass-through message:
-if incoming message has no topic, the outgoing message would be (first choice) the config topic (if it exists), or (second choice) no topic
-if incoming message has a topic, the outgoing message would be the config topic (if it exists, overwrite the incoming topic) or the same as incoming message (if no config topic)

For messages originating in the node:
-messages should be the config topic if it exists
-if no config topic, I would expect outgoing messages to match whatever the most recent incoming topic was

This is the "normal" way for topic to work in nodered. I've seen other nodes use this convention. Based on the code, and bug report, I think this is what the node is doing?

I use topic a lot in my flows. I have the topic for everything homekit set in the node and haven't ever had issues.

In response to the bug report-
The config of the node is not being set by the incoming messages. Restarting nodered should wipe any previous "remembered" topic, unlike a config which will be remembered. It's just using the latest incoming topic if there's not any topic set by the config.

And now - does anyone have a reason it should work differently from how it is?

from node-red-contrib-homekit-bridged.

Closing as no update from author. Let's keep the topic feature as is for now, until any strong arguments appear.

from node-red-contrib-homekit-bridged.