Integrating ChirpStack (on-premise) with external Energy Management Systems

1. This is hard to say, as it depends on the skills of your team. However, setting up a simple ChirpStack instance should not be very complex and you can find guides in the documentation.

2. Please note that MQTT (depending on the QoS) is not intended for queueing data. E.g. if telemetry data is critical, you might want to opt for any of the other integrations (e.g. PostgreSQL) to first store the data and then periodically import these in your EMS system.

As a solo dev fresh out of uni, with only basic understanding of networks and no initial understanding of LoRaWAN, I set up a Chirpstack deployment for our company with a custom user portal, multiple gateways and 50ish devices (for now). I'd personally say that the floor is low and the ceiling is high. Only took a day or two to have a working Chirpstack deployment, but a couple months to truly feel comfortable with my understanding of all the inner workings, a fair bit of that was general LoRaWAN understanding though and not necessarily Chirpstack specific learning. Then it took a few more months on and off to have a production worthy setup.

The real difficulty with production deployments is not base Chirpstack itself, but all of the other steps you need to take to make an individual software service (chirpstack or not) reliable in large. Things like high availability, redundancy, monitoring, automated back ups, are not pre-packaged in Chirpstack like they may be in other paid network servers. Though Chirpstack makes it relatively easy to implement those features yourself.

If your team is already familiar with working in docker and deploying high availability clusters (using kubernetes, docker swarm, etc...) and setting up automated health checks and monitoring this shouldn't be a big deal, but it will take some time.

As for the EMS system, as Brocaar said MQTT is a pub/sub broker and is not intended to store data for something like a 15 minute exporter, although I would expect if the EMS takes MQTT it does it in realtime and not by 15 minute increments, in which case it would be easy to integrate with Chirpstack. With MQTT QoS (Quality of service) settings, you can guarantee the messages get through in the case of occasional packet loss, but in an outage for longer then a few minutes with that many devices you will lose data. There are plenty of other integrations you can use that are more meant for that purpose. We use the EMQX integration (essentially MQTT with queues) for Chirpstacks connection to our custom user portal.

In about a year of operating I have not seen Chirpstack fail, Brocaars done a great job and it really is quite reliable. The real concern is in LoRaWAN itself and the hardware you use, servers fail, gateways fail, devices fail and Chirpstack itself is a lossy protocol. TTN itself says to expect ~10% packet loss with unconfirmed uplinks (I typically see about 6% daily on our network), and confirmed uplinks are far from ideal as they bottleneck your gateways much faster. I'd say any potential Chirpstack issues are negligible compared to the innate lossy-ness of Chirpstack