There’s now a program that will listen for all the messages sent to the MQTT broker and log it to a csv file. This is useful to store the data. Right now, the parameters that are saved are simply the date, time since the epoch, topic, payload, qos and retain. It was interesting to see the retained messages on the server be instantly sent when the logger program subscribed to the topics. There is currently one uncertainty with the code, the logger opens and closes the file each time it is being written. Will this become a bottleneck when there will be plenty of messages and a queue forming? It will be interesting to test. For a prototype, it works. The next step was to write the intelligence program. That was simple, and it is complete too. The next step following that is to find the real sensors electronics for the device.
The device simulator is now generating values and sending through MQTT. The values get displayed and updated live on the AR marker overlay without glitching. A few days ago making elements clickable was figured out. This will be useful when there’s a need for buttons on the AR view. The topic structure was updated as well. The next step will be to make the device send and receive the data. The AR program is not set up for multiple devices or markers just yet. That will be future work as well.
AR markers triggering messages to send to the alternate (secure) MQTT server is working. The preliminary topic structure was chosen, which gives each marker type its own topic, and sends the state when it enters the view, still in the view, and exits the view. Next step is to make sure the device can receive these messages, and have the device send its sensor data – only when the marker is in view (as to not overload this MQTT server (since it isn’t running on our AWS)). As well, next step is sending a marker state heartbeat when it is in view.