LightMQTT
LightMQTT copied to clipboard
Any implementation of Will topics
Hi, I am interested in using will topics. How can I do that??
Thanks
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.
@PasiSalenius I have sent a PR #22 . Kindly check it out. Cheers!!
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.
@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.
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 [email protected]:
@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 https://github.com/PasiSalenius/LightMQTT/issues/18#issuecomment-487049752, or mute the thread https://github.com/notifications/unsubscribe-auth/AG3UG7ZIEWYX5NCF2WIEQMTPSL44NANCNFSM4DUBWBGQ.
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 [email protected]:
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 <[email protected] mailto:[email protected]>:
@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 https://github.com/PasiSalenius/LightMQTT/issues/18#issuecomment-487049752, or mute the thread https://github.com/notifications/unsubscribe-auth/AG3UG7ZIEWYX5NCF2WIEQMTPSL44NANCNFSM4DUBWBGQ.
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.
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 [email protected]:
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 https://github.com/PasiSalenius/LightMQTT/issues/18#issuecomment-487062096, or mute the thread https://github.com/notifications/unsubscribe-auth/AG3UG76C7PXEVLN2QQU5ZSTPSMBM3ANCNFSM4DUBWBGQ.
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 https://github.com/PasiSalenius/LightMQTT/commit/6074529387618f0395017347db7aa77344314429.
Thanks for your fix, but it doesn’t solve my issue, unfortunately.
Am 27.04.2019 um 14:41 schrieb Pasi Salenius [email protected]:
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 https://github.com/PasiSalenius/LightMQTT/commit/6074529387618f0395017347db7aa77344314429.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PasiSalenius/LightMQTT/issues/18#issuecomment-487282946, or mute the thread https://github.com/notifications/unsubscribe-auth/AG3UG76LEI5MDQN2HWQIWGLPSRCWBANCNFSM4DUBWBGQ.
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 [email protected]:
Thanks for your fix, but it doesn’t solve my issue, unfortunately.
Am 27.04.2019 um 14:41 schrieb Pasi Salenius <[email protected] mailto:[email protected]>:
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 https://github.com/PasiSalenius/LightMQTT/commit/6074529387618f0395017347db7aa77344314429.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PasiSalenius/LightMQTT/issues/18#issuecomment-487282946, or mute the thread https://github.com/notifications/unsubscribe-auth/AG3UG76LEI5MDQN2HWQIWGLPSRCWBANCNFSM4DUBWBGQ.
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 [email protected]:
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 https://github.com/PasiSalenius/LightMQTT/commit/6074529387618f0395017347db7aa77344314429.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PasiSalenius/LightMQTT/issues/18#issuecomment-487282946, or mute the thread https://github.com/notifications/unsubscribe-auth/AG3UG76LEI5MDQN2HWQIWGLPSRCWBANCNFSM4DUBWBGQ.
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.