Closed spatsatzis closed 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.
Great @brocaar thanks for the comments, I'm making some changes right now and when I'm ready I will comment back.
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 !
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.
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.
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 !
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!
More about this PR here
Please take a look and let me know what do you think
thanks!