Monthly Archives: January 2021

Kootnet Sensors MQTT Update

I have updated MQTT publishing and subscribing. There was nothing ‘wrong’ with the publishing, but I have made it more efficient by grouping all the readings to be sent into a single list made of dictionaries and sending it all at once, instead of publishing each one individually.

The MQTT Subscriber on the other hand was dropping data a lot, some sensors would only give one or two readings and never anything else, while others only randomly showed readings. I managed to fix it by using callback access inside the Python MQTT library instead of a client connection. Now all the data comes through every time.

The next step will most likely be updating graphing to allow the use of the MQTT subscriber database. I also wanted to add the ability to upload different databases for use in graphing as well as adding the ability to save multiple IP lists in remote management.

The new version has been uploaded to the Dev channel and is ready to try, which is currently Beta.32.12.

Kootnet Sensors progress

I have finally started poking at programming again. To start, I have fixed a bug in Kootnet Sensors when updating configurations of the 3rd party services. After that, I added the ability to record MQTT subscriber data to a separate MQTT SQLite database. This means you can centralize your sensor recordings, AKA send multiple sensor readings from multiple Kootnet Sensors to a single MQTT broker, such as a Kootnet Sensor and have any Kootnet sensor subscribe to the broker and record all the readings. Since MQTT is being used to transmit data, the remote recording is very flexible, for instance, you can get all readings being sent to the MQTT broker or specify specific sensors and or readings. This also means you can have multiple sensors recording data from the MQTT broker, to have redundant copies of the data for backup purposes for example.

I decided to send data over MQTT as dictionaries in string format, this way the ‘name’ in the dictionary is used as the SQL database column and the data is the sensor reading, at least that’s what I have done with sensors that have more then one data point (Magnetometer for example). I’m still debating if I should do the same for the single readings, as I’m currently using the end MQTT topic as the column name for single data point sensors (the base topic being the sensors name/ID). I suppose leaving it as is will decrease the amount of data it needs to send … I’ll have to give it some more thought.

The program changes have been published to the development channel.

That’s it for now.