I know how to retrieve a (zipped) JSON file with the status of all devices (Settings → Tools → Download states).
Is it possible to access these data via an API, or otherwise download the JSON file?
The states are in HA and you can retrieve them like any other state.
Publish zigbee2mqtt/bridge/devices #
Contains the devices connected to the bridge. Whenever a devices joins or leaves this is republished. In case supported is false, definition will be null.
@nickrout @francisp Thank you.
I was hoping for an API access because I saw that https://zigbee2mqtt.examlple.com/#/settings/bridge provides (among others) the list of devices, and then https://zigbee2mqtt.example.com/#/device/<deviceId>/info gives (again, among others) the last seen timestamp.
I wanted to avoid scrapping the data from the site (especially that the last seen time I provided in a relative format).
The main reason why I want to avoid MQTT is that this is for monitoring purposes (I use my own monitoring system for my home appliances and services) and I do not want to have dependencies (not to mention that an event-based solution such as MQT is not ideal for monitoring purposes). Same goes for HASS (which I use as well for other data to monitor)
Well, as long as the messages are retained, that’s not really an issue.
Although I understand your concern regarding dependencies, you can safely assume that if your MQTT is down, so are the entities 
Monitoring via MQTT requires my monitor client to either be constantly connected to the broker (I would like a one-shot program) or to arbitrarily assume that "ok, I connected to the broker, and by now (1, 10, 100 seconds) I retrieved all the retained messages.
I currently do the former but would like a standalone, one-shotp program.
As for MQTT, yes, this is basically the end of the world in terms of home automation, I agree.
I find it surprising, though, that Zigbee2MQTT has an internal DB of the states (per the various pages) but does not expose an API (but it does allow a download of the zip file with these data).
Where did you see this?
I don’t see any difference between the material from the web interface download and the material available from the mqtt broker.
A monitoring program as used by @wojwoj can simply do two mqtt queries and get the sought data. It doesn’t have to be continuously connected to the broker.
I don’t see any difference between the material from the web interface download and the material available from the mqtt broker.
There is one big difference: the API (or the downloaded JSON data) is synchronous. I know that once I received the data, it is all the data.
The MQTT broker does not guarantee when the retained data will be sent to the client. This is usually “instantaneous” (you see them arriving in , say, 2 seconds) but there is no guarantee. This si normal and part of the specification.
For a monitoring system, I would prefer to get the date in a predictable way.
can simply do two mqtt queries and get the sought data
What do you mean by two queries?
You wanted those 2 pieces of data, therefore 2 queries.
What I have found is that I can connect and issue my subscribes, wildcarded or not. Then I subscribe to one fixed and unrelated topic. When I get the payload back for that last topic I am pretty confident the previous subscribes have all completed. I have yet to find this is not correct although I do know the guarantee isn’t there.
I recognise the point about mqtt, but I have found that zigbee2mqtt with eclipse mosquitto is very responsive and if you to a mosquitto_sub it will respond immediately with up to date info.
@nickrout
I recognise the point about mqtt, but I have found that zigbee2mqtt with eclipse mosquitto is very responsive and if you to amosquitto_subit will respond immediately with up to date info.
I understand and I see the same behaviour (I use the broker for other services than home automation, and heavily rely on it and on the protocol).
I was just wondering if there was a way to programmatically retrieve the information in the JSON zip file (as it has everything) since it is obviously there anyway (or, alternatively, the data present in the two links I mentioned, which can be combined to get the same data that is in the JSON file (at least the part that is interesting to me in the context of the monitoring)).
If not I will go the MQTT way (as I do today).
They are very likely to be there (this is what I see as well) but when I read the protocol specs some time ago, there was no concept of queuing, it was all async. This means that your (very good) idea to “flush” the subscribed data through a 2-step subscription is not guaranteed.
In fact, I am not really trying to find the optimal way to work with MQTT in that case (what I do is experimentally “good enough”) but rather to make sure that the consolidated, synchronous data available in the frontend is not retrievable through an API or download or whatever.