Issue #5 has re-appeared

[BNNorman]

If you click on the top device in my cluster it opens on a no-data page.

[sbrl]

Hrm, I see! I think this might be related tot he database issue in #6.

I theorise that the system is assuming that data is available for PM25 when the relevant API call returns it in the list of supported measurement types.

Removing the redundant data from the system should take care of this.

[BNNorman]

Need to check if robin did that.

[BNNorman]

Actually your theory is faulty. If there's extra data why do i get a popup saying 'no data'. I theorise you have two sql statements one says there is data and the other says not.

[BNNorman]

Oddly, it's behaving this morning - you been fiddling?

[sbrl]

Nope! Haven't fiddled with it since the last message.

The query that returns the data itself looks only within the specified time-frame. The query that determines whether a given device actually has any data of a given measurement type associated with it does not have any restriction on time-frame.

....perhaps I should alter it such that the latter query is restricted by time-frame, but that would introduce a significant amount of complexity.

[BNNorman]

Ok. Well what has happened is very odd unless tbe broker script thinks there's data. Sto?l need to talk to robin.

[BNNorman]

Found out why the problem disappeared again. Something has put pm values in for brian01 that should not be there. Robin and i are looking at the subscriber code. I suspect a global variable is responsible and that it happens when a new message arrives before a prior message has been fully dealt with.

[sbrl]

Cool! Sounds like we've found the issue. I'll transfer this issue over to the new MQTT repository.

[sbrl]

Oops! I don't appear to have admin privileges on the new repository, so I can't transfer it.

[BNNorman]

I'd wait. A new script is now in place and a newer one being written. I'll close this one.

[sbrl]

Ok. Thanks, @BNNorman!

[BNNorman]

I'll have a go at removing redundant dat