Thanks, I tried to do exactly that in my code above (though I actually added the connect statement like in that example). But I still never seem to get the "connect" event.
I also took a look at the built-in node it never actually calls connect. But in my case when it enters my function the brokerConn is never connected. What is odd is that the status on the flow shows up as green and connected. But that doesn't appear to be because of my code...
Nope - the core nodes are on a pretty level playing field with anything else. The only exceptions are the Link, Status and Catch nodes are they have more fundamental runtime behaviour.
The challenge here is more the mqtt-broker node hasn't been written to be a generically reusable mqtt client node. It serves the needs of the mqtt-in and mqtt-out nodes, which may or may not be all that is needed.
Having spoken to Scott on slack, his node needs to know specifically when the connection comes and goes - something the core mqtt nodes don't care about themselves. So the mqtt-broker node doesn't expose it directly. I have shown him how to access the raw mqtt client used by the mqtt-broker node to access the finer-grained events he needs.
That does put more of a burden on us not to change the internal implementation of the node; I'd prefer it if this was raised as a more general requirement and a proper design put in place that we could have confidence of in the longer term...
Thanks. Yea, I am not in favor of just leveraging the implementation directly.
I suppose one option would be to expose some functionality (like events for 'connect'). But even then it would be pretty hard for someone to write a node that leveraged it since it is possible for the connection to be established before the node is called (seems unlikely, but there is basically a race condition).
I think for my particular case I may as well just manage my own connection since I shouldn't need it around for very long so I think I can take care of it.
So I had some thought on my drive in (it's not a long drive, so I haven't thought this through completely!).
It is clear that there is an attempt to allow custom nodes to share MQTT connections within Node Red; I think this is great. But for reasons above it is not possible for custom nodes to know when the connection changes.
I think this could be addressed by doing just two things:
Promoting connection related events to all registered nodes
When a node is registered, fire the current connection state to the newly registered node.
Nick, thanks for the clarification. I think I ran into this while trying to embed the link node functionality in a custom node. The ui looked ok, but no events were passed. Is this a deliberate design choice? likely to be a permanent limitation?
I hate to wake an old thread, but this is the only info I've found accessing the MQTT broker client connection inside of a custom node.
I have a similar requirement as the OP. I'm not quite following what you were talking about in your post about talking to Scott and helping him get to a solution.
Is there a way for me to publish/subscribe from within a custom node's code-behind?
My entire project is based around MQTT, and having to string dozens, or even hundreds, of MQTT in/out nodes everywhere, is far too much boilerplate. I would love to be able to roll my own nodes, and just access the existing MQTT client connection to let it handle the work.
Is this possible or am I just missing the solution in the above conversations?
I think that what Nick was saying was simply that currently, you have to replicate what the mqtt in/out nodes do internally. If you use the same MQTT library, you can reuse much of the code through copy/paste into your own node.
Just make sure that you make the client id unique for every node instance.