Any implementation of Will topics

[ameykshirsagar]

Hi,
I am interested in using will topics. How can I do that??

Thanks

[PasiSalenius]

This is not supported at the moment. The client library is best at simple use case of subscribing to topics and receiving messages, this is what I use it for.

You're welcome to send PRs for changes that you think are needed.

[ameykshirsagar]

@PasiSalenius I have sent a PR #22 . Kindly check it out.
Cheers!!

[df1gr]

Hi,
using LightMQTT to connect and subscribe successfully to owntracks-MQTT.
I can get some messages from Owntrack. However, after few messages it seems to stop receiving from Owntracks. Seems for me, LightMQTT sleeps. When I restart my program messages transfer continues. Using LightMQTT in Swift main program on MacOS 10.4.4. Is there any idea why this hangup is happen? Thank you in advance for any hint.

[PasiSalenius]

@df1gr The default ping interval is 10 seconds, you can try reducing that and see if it helps.

I've also seen similar behaviour with one MQTT server, and could not really figure out what was causing it. Receiving payloads for some seconds but then stopping, until I force quit the app and started it again.

With the main MQTT server I'm using, I never see this issue.

[df1gr]

Thanks Papi, tried with ping interval 1 second, but same effect. However, got "2019-04-26 15:10:42.970630+0200 LightMQTT[1241:77516] SocketStream read error [0x600003701e00]: 1 54“ after few payloads. The MQTT server responded with ‚publish queued on user request‘. Any idea? Regards, Roland Am 26.04.2019 um 15:06 schrieb Pasi Salenius <notifications@github.com>: @df1gr <https://github.com/df1gr> The default ping interval is 10 seconds, you can try reducing that and see if it helps. I've also seen similar behaviour with one MQTT server, and could not really figure out what was causing it. Receiving payloads for some seconds but then stopping, until I force quit the app and started it again. With the main MQTT server I'm using, I never see this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3UG7ZIEWYX5NCF2WIEQMTPSL44NANCNFSM4DUBWBGQ>.

[df1gr]

Hi, found some Note on the Owntracks documentation, which could bne helpful resolve the problem: ' In MQTT mode the server will consider the client as dead if it the keepalive interval plus 50% passed without receiving any MQTT packet from the client (e.g. after 90 sec if keepalive was 60). Afterwards, an lwtmessage will be send.’ Is keepalive some protocol which LightMQTT must send to the server? I’m using Mosquitto. Regards, Roland Am 26.04.2019 um 15:15 schrieb Roland Hartinger <roland@rolandhartinger.de>: Thanks Papi, tried with ping interval 1 second, but same effect. However, got "2019-04-26 15:10:42.970630+0200 LightMQTT[1241:77516] SocketStream read error [0x600003701e00]: 1 54“ after few payloads. The MQTT server responded with ‚publish queued on user request‘. Any idea? Regards, Roland Am 26.04.2019 um 15:06 schrieb Pasi Salenius <notifications@github.com <mailto:notifications@github.com>>: @df1gr <https://github.com/df1gr> The default ping interval is 10 seconds, you can try reducing that and see if it helps. I've also seen similar behaviour with one MQTT server, and could not really figure out what was causing it. Receiving payloads for some seconds but then stopping, until I force quit the app and started it again. With the main MQTT server I'm using, I never see this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3UG7ZIEWYX5NCF2WIEQMTPSL44NANCNFSM4DUBWBGQ>.

[PasiSalenius]

The pingInterval parameter of the LightMQTT.Options struct defines the interval at which the server expects to receive ping MQTT messages, and LightMQTT will send pings at half of that interval. So that should keep the connection alive to the server.

I would very much appreciate if you can debug and find the cause of the issue using your setup, as different MQTT servers seem to behave differently here.

[df1gr]

Hi Pasi, tried to debug the problem, but is difficult. But, I had a look to your code:# private func delayedPing() { let interval = options.pingInterval let time = DispatchTime.now() + Double(interval / 2) DispatchQueue.global(qos: .default).asyncAfter(deadline: time) { Is the red marked code correct? Since DispatchTime.now() return the actual time in nano seconds and you add interval / 2 which has the unit seconds. Couldn’t this lead too fast pings which is incorrectz for some brokers? Juat an idea! Regards, Roland Am 26.04.2019 um 15:44 schrieb Pasi Salenius <notifications@github.com>: The pingInterval parameter of the LightMQTT.Options struct defines the interval at which the server expects to receive ping MQTT messages, and LightMQTT will send pings at half of that interval. So that should keep the connection alive to the server. I would very much appreciate if you can debug and find the cause of the issue using your setup, as different MQTT servers seem to behave differently here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3UG76C7PXEVLN2QQU5ZSTPSMBM3ANCNFSM4DUBWBGQ>.

[PasiSalenius]

I don't think this is what causes your disconnection issues, but thanks for pointing that out. I already commited a fix for it in 6074529.

[df1gr]

Thanks for your fix, but it doesn’t solve my issue, unfortunately. Am 27.04.2019 um 14:41 schrieb Pasi Salenius <notifications@github.com>: I don't think this is what causes your disconnection issues, but thanks for pointing that out. I already commited a fix for it in 6074529 <6074529>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3UG76LEI5MDQN2HWQIWGLPSRCWBANCNFSM4DUBWBGQ>.

[df1gr]

Sometimes,, my app breaks with the following errors, after a few messages are received: 2019-04-27 15:56:02.750416+0200 LightMQTT[4794:259511] [] nw_socket_handle_socket_event [C1.1:1] Socket SO_ERROR [54: Connection reset by peer] 2019-04-27 15:56:02.817122+0200 LightMQTT[4794:259378] SocketStream write error [0x600003700180]: 1 32 Does this help to diagnostics? Am 27.04.2019 um 14:51 schrieb Roland Hartinger <roland@rolandhartinger.de>: Thanks for your fix, but it doesn’t solve my issue, unfortunately. Am 27.04.2019 um 14:41 schrieb Pasi Salenius <notifications@github.com <mailto:notifications@github.com>>: I don't think this is what causes your disconnection issues, but thanks for pointing that out. I already commited a fix for it in 6074529 <6074529>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3UG76LEI5MDQN2HWQIWGLPSRCWBANCNFSM4DUBWBGQ>.

[df1gr]

Pasi, I have investigated in our relative complex multi-broker configuration and found double usage of a clientId. After correcting it, it seems all working well. Thank you for your kind support last days! Roland Am 27.04.2019 um 14:41 schrieb Pasi Salenius <notifications@github.com>: I don't think this is what causes your disconnection issues, but thanks for pointing that out. I already commited a fix for it in 6074529 <6074529>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG3UG76LEI5MDQN2HWQIWGLPSRCWBANCNFSM4DUBWBGQ>.

[PasiSalenius]

I'm very glad to hear that. That got me thinking I also need to make sure I wasn't accidentally using the same clientId repeatedly during one development phase.