search

chirpstack / chirpstack-gateway-bridge

ChirpStack Gateway Bridge abstracts Packet Forwarder protocols into Protobuf or JSON over MQTT.
https://www.chirpstack.io
MIT License
425 stars 273 forks source link

Issue #85 - Adding MQTT Last Will message #87

Closed spatsatzis closed 6 years ago

spatsatzis commented 6 years ago

More about this PR here

Please take a look and let me know what do you think

thanks!

brocaar commented 6 years ago

Thanks @spatsatzis and sorry I didn't reply earlier to your issue. Great that you already moved forward with this 👍 I'll review your changes and add some inline feedback where needed.

spatsatzis commented 6 years ago

Great @brocaar thanks for the comments, I'm making some changes right now and when I'm ready I will comment back.

spatsatzis commented 6 years ago

Hello @brocaar just made the changes you suggested, take a look and let me know. I need your help in getting the mac address though, (sorry but it's my first time with Go :) )

thanks !

brocaar commented 6 years ago

Thanks @spatsatzis and sorry for the delay. My first prio in the past weeks was getting LoRa (App) Server v2 out. I will review your changes this week.

brocaar commented 6 years ago

Thanks again for your time to go through my feedback. I've been thinking about this, but my main problem is that I don't want to make this to generic as potentially every gateway could send a different payload (and re-configuring all gateways might not always be easy).

Also by defining the payload manually, this could become problematic when Protocol Buffers based serialization will be implemented (see also https://forum.loraserver.io/t/gateway-bridge-on-gateway-vs-in-cloud-latency-and-overhead/1107/8). E.g. what would one enter as payload in such a case? Or would the last will not use the selected marshaler in this case?

On the other hand, as LoRa Gateway Bridge is able to serve multiple gateways, it is also not possible to use a single gateway ID / MAC. Or it could send a slice of gateways it is serving. But still I'm not sure if this is the best way to monitor the LoRa Gateway Bridge health. As there are multiple steps (UDP > LoRa Gateway Bridge > TCP / MQTT), monitoring the actual performance gives a better indication I think. This will be something that will be possible using Prometheus based metrics.

I understand that this feature could be useful for your use-case, but would you mind if I decide to not merge this pull-request? Currently I don't have a clear view on how this would be integrated into LoRa Server.

spatsatzis commented 6 years ago

Hey @brocaar sorry for late reply, it could be set to some hard coded payload, like {"STATUS":"OFFLINE","BRIDGE_ALIAS":"MY_NAME"} and then no configuration is needed, it will monitor the health of the bridge in general. We can leave the option though in configuration file, if someone wants to play around with the bridge installed on the gateway as in my case, it will override the default.

I don't know a lot about Protocol Buffers, so I can't discuss about it right now, I'm in cellular and considered about JSON size (usage MB), so I'll read the link you gave.

The purpose of this "feature" won't be to monitor the health, it would be like an "alarm/notification" that something went wrong. My network is based on cellular so my data usage must me limited, I'll give Prometheus and Grafana a try and see if it helps better my case.

Thanks for your time, I understand your concerns about this pull request and there is no problem from my side if you decide not to proceed.

thanks !

brocaar commented 6 years ago

I'm closing this for now. I do see where this could be useful, but currently I'm not 100% sure how I could integrate this with LoRa Server. There is also a case (to be announced later this month) where this will not work / might break.

I will keep your feedback in mind!