Re: [mosquitto-dev] Bridging on a wakeup or connection

["Bradley, Dwayne" <Dwayne.Bradley@xxxxxxxxxxxxxxx>]

Since we can already get data about the broker from the $SYS/# topics, would it make sense to have a topic under this for commands or even a $CMD/# set of topics?  Just a thought.

Dwayne

-----Original Message-----
From: mosquitto-dev-bounces@xxxxxxxxxxx [mailto:mosquitto-dev-bounces@xxxxxxxxxxx] On Behalf Of Ian Craggs
Sent: Wednesday, July 23, 2014 6:18 PM
To: mosquitto-dev@xxxxxxxxxxx
Subject: Re: [mosquitto-dev] Bridging on a wakeup or connection

*** This is an EXTERNAL email.  Exercise caution.  DO NOT open attachments or click links from unknown senders or unexpected email. ***

I fully agree on using signals.  But as you said, they're limited in number, and the number of interpretations you can put on them.  For fully flexible commands, if we use MQTT because we already support it, it helps keep the server small too.

It's pretty easy to send an MQTT message from a shell script too, with mosquitto_pub, or stdinpub as I called it :-)

Ian

On 23/07/14 15:55, Frank Pagliughi wrote:
> Yes, that makes a lot of sense... In the "how do we send messages to a 
> message-processing server" kind of way.
>
> I mentioned using Linux OS signals for two reasons:
> 1. Mosquitto already handles signals (SIGHUP, SIGUSR1, & SIGUSR2). So 
> it should be easy to extend this.
> 2. It's trivial to send a signal from a shell script, which is how the 
> system would be notified of being ready... through ppp-up or APM resume.
>
> But you can only handle a few commands with signals. Something better 
> is required if you have a long list of commands that you want to 
> implement.
>
> Frank
>
> On 07/23/2014 10:41 AM, Ian Craggs wrote:
>> Yes, I agree that using a special command topic with MQTT is the best 
>> solution (command responses could be sent to a special topic based on
>> clientid) as long as it's secure.  The only reason I didn't choose 
>> that method in RSMB was because of the absence of built-in security 
>> at the time.  Using a command file meant that the OS security could 
>> be used.
>>
>> Ian
>>
>> On 07/23/2014 02:17 PM, Davis, Charles wrote:
>>> I also had a need to send commands to Mosquitto.  I implemented a 
>>> mechanism for a client connected as an authorized user to send 
>>> commands using normal MQTT publish to a special topic.  The 
>>> mechanism is rudimentary in that there is no output to the client in 
>>> response to the command, but it works for my situation.
>>>
>>> -----Original Message-----
>>> From: mosquitto-dev-bounces@xxxxxxxxxxx 
>>> [mailto:mosquitto-dev-bounces@xxxxxxxxxxx] On Behalf Of Ian Craggs
>>> Sent: Wednesday, July 23, 2014 5:41 AM
>>> To: mosquitto-dev@xxxxxxxxxxx
>>> Subject: Re: [mosquitto-dev] Bridging on a wakeup or connection
>>>
>>> #1 In RSMB, I have the capability to stop and restart bridges with a 
>>> command (read from a file).  And create new ones.  I think it would 
>>> be good to add that to Mosquitto, but Roger was wondering how to 
>>> best accept commands in Mosquitto, last time we discussed the topic.
>>>
>>> #2 that could be done via MQTT?  Mosquitto could send some 
>>> information about the bridge starting (I think there might be a 
>>> state change already indicated).  Of course there would have to be 
>>> an MQTT client running to listen for the signal and start the modem 
>>> call.
>>>
>>> Ian
>>>
>>>
>>> On 07/22/2014 07:31 AM, Frank Pagliughi wrote:
>>>> Hi,
>>>>
>>>> I'm testing out using Mosquitto on an embedded ARM board as a means 
>>>> of sending messages between the on-board apps. Everything is good there.
>>>> Now I'm starting to play with bridging the broker to remote servers 
>>>> to get data off the board. When awake and connected to a LAN, it's 
>>>> working fine, but there are two situations with a similar pattern 
>>>> that I need help with:
>>>>
>>>> (1) The board is asleep most of the time, and the Ethernet 
>>>> controller powers down in suspend mode, severing TCP connections to 
>>>> the LAN. The board only remains awake for 5-10sec at a time. So 
>>>> immediately upon resume, it would be great to kick the broker to 
>>>> tell it to reconnect the bridge(s) and start pumping out the messages.
>>>>
>>>> (2) The machine may be deployed in a remote location with a 
>>>> cell/satellite modem in which case it has no LAN. It still wakes 
>>>> every few minutes, but only once every few hours does it power up 
>>>> the modem and make a short phone call to upload data.
>>>>
>>>> In the first case it may suffice to use automatic "start_time" and 
>>>> use a very small "restart_timeout" - like 1. The broker wouldn't
>>>> (couldn't) thrash through the suspend, and would reestablish the 
>>>> connection very quickly on wakeup. I assume.
>>>>
>>>> But in the second case, it would be better for the broker to not be 
>>>> re-trying constantly, using CPU and battery time. What could I do 
>>>> here? Is there an existing configuration that might work?
>>>>
>>>> But into the future...
>>>>
>>>> Wish #1:  It would be cool in either case to be able to give the 
>>>> broker a kick to say, "try to reconnect your bridges now". 
>>>> Obviously a signal would do the trick. It could be sent from a 
>>>> ppp-up or resume script.
>>>>
>>>> Wish #2: In the second (modem) case, the other way around might be 
>>>> a way to go. Rather then the system telling mosquitto when it's 
>>>> time to reconnect, mosquitto could tell the board when it's time to 
>>>> place a call. Use "lazy" startup with a threshold count, and have 
>>>> the broker emit a signal of some sort (maybe run a script or system 
>>>> command) when it's time to make a connection. Allow the system to make the call.
>>>> Emit another signal when the idle_timeout expired (hang up the phone).
>>>>
>>>> Thanks,
>>>> Frank
>>>> _______________________________________________
>>>> mosquitto-dev mailing list
>>>> mosquitto-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or 
>>>> unsubscribe from this list, visit 
>>>> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
>>> --
>>> Ian Craggs
>>> icraggs@xxxxxxxxxx                 IBM United Kingdom
>>> Committer on Paho, Mosquitto
>>>
>>> _______________________________________________
>>> mosquitto-dev mailing list
>>> mosquitto-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or 
>>> unsubscribe from this list, visit 
>>> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
>>> Please visit us at http://www.teletech.com 
>>> ............................................................
>>> This EMAIL and any attachments may contain confidential, proprietary 
>>> and/or privileged information.  If you are not the intended 
>>> recipient, please immediately notify the sender by return email, and 
>>> delete this communication and any copies. Any dissemination or use 
>>> of this information by a person other than the intended recipient is 
>>> unauthorized and may be subject to criminal and civil proceedings.
>>> Unless otherwise stated, opinions expressed in this email are those 
>>> of the author and are not endorsed by TeleTech Holdings.
>>> ............................................................
>>>
>>> _______________________________________________
>>> mosquitto-dev mailing list
>>> mosquitto-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or 
>>> unsubscribe from this list, visit 
>>> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
>>
>
> _______________________________________________
> mosquitto-dev mailing list
> mosquitto-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit 
> https://dev.eclipse.org/mailman/listinfo/mosquitto-dev

_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mosquitto-dev