Small issues with log

[flatsiedatsie]

I have a few small niggles with the log:

• The text is unreadable (click on the picture to see the issue). Looking at the CSS, the text is black, and then gains a "stroke:white" which seems to try and create a white outline on the 10pt black text, which the unreadable result seen above. Platform: Firefox 66, MacOS.

• Similarly, the icon in the top left seems a little too small?

• There could be a hyphen between device name and property name. In the example above the device is called "Temperature and more", and one of its properties is Temperature. So Temperature and more Temperature could perhaps be: Temperature and more - Temperature

• The first datapoint in the graph is shown for the entire history of the log. So now it looks like the entire last week it was 23 degrees. Could the log perhaps not display anything to the left of the first datapoint?

[hobinjk]

I'm unable to reproduce the text color issue on the same version/OS combo but I do see why it could happen. I can set the fill as a fallback for cases where the stroke isn't covering it (maybe it's related to display DPI setting the default stroke width?)

The reason for drawing a line backwards from the first datapoint like that is to make it clear that there's data on the graph since many people would miss the few data points all the way at the right and be worried that the logging wasn't working. It's definitely not a perfect solution and I think some kind of no data/fade out effect would be good

[flatsiedatsie]

Another small one: my sensor gave an erroneous, very strange outlier value. It ruins the display of all the other values. I don't think this has to be fixed (with some time the problem will go away), but I thought I'd bring it up anyway.

[flatsiedatsie]

Something strange happens when you change your timezone.

After adding a log I noticed that the clock on the Pi was behind. So I changed it to the correct value.

Now, all values that are added seem to be added at the correct time.. but they don't become visible until two hours later. It's as if the log still uses the old timezone to determine the window it displays.

I tried deleting all logs and rebooting, but the time effect was still there.

[dhylands]

The time on the Pi should be UTC time. This is what NTP should be setting it to.

Presumably, each user should have a timezeone setting (I don't think we have this right now) and when that user is logged in, we should be showing the times in that user's local time.

[flatsiedatsie]

That would be one option.

Personally I would prefer to be able to set both the locality and the time. In my opinion no smart home should ever rely on the cloud / go 'cloud default'.

In my use case the Gateway will never be connected to the internet. It will be an internet island, separate from the rest of the world, and separate from the home network too.

[madb1lly]

Hi @hobinjk,

Re: "The first datapoint in the graph is shown for the entire history of the log." and "The reason for drawing a line backwards from the first datapoint like that is to make it clear that there's data on the graph since many people would miss the few data points all the way at the right and be worried that the logging wasn't working."

This causes a problem when something doesn't change for a long time, because the log doesn't record continuously, it only seems to record changes (which is fine, to reduce data archive size), when it does change the log graph plots a line between the two last different data points. In my case, it didn't change for four days but it was a step change today, so it should appear as a step on the graph, but instead it is plotted as a gradual increase over the past four days, which is misleading.

The fix is that whenever the value changes, record the previous state immediately before the new state, that way the graph will look correct.

Note I haven't looked at the code for this, so I've a made some assumptions - please tell me if I'm wrong.

Tell me I should raise this as a new issue.

Cheers :)

[hobinjk]

@madb1lly If the property type is set to "integer" or "boolean" all changes are represented as step changes. If the property type is "number" then it will interpolate. I found this to work for most cases since we don't know the sample rate of each underlying sensor. There are a few workarounds for DIY webthings where removing interpolation is necessary (e.g. a scale which will have sharp transitions between 0 and a floating point weight). The simplest is that you could occasionally perturb the underlying value by 0.00001 to make sure that the graph will extend the data with only a small amount of interpolation. The other would be to debounce changes and pair every change with a perturbation and brief delay so instead of [value, newValue] it's [value, value + 0.0001, newValue]

[flatsiedatsie]

As an aside: any idea how the timezone issue can be fixed manually? I'm doing that things that require insight into the logs, but I always have to wait 2 hours before the results finally become visible in the log.

[hobinjk]

My guess would be to reset the Pi to UTC time

[flatsiedatsie]

Thanks. After I changed the time via raspi-config' to UTC, and tried tosudo systemctl restart mozilla-iot-gateway.service`, the restart proces froze. A reboot of the Pi solved the issue, and the log now at least shows new data immediately.

Any idea what could be causing the log to not use the system date as the logging display date?

[flatsiedatsie]

I also had an issue where if I changed the display between hour/day/week a bit, eventually the graph would look empty, and show one datapoint dot on the very left edge of the screen.

[flatsiedatsie]

Another small thing:

I dragged the slider all the way to the right. But it didn't move the graph to 'now'. I had to click on the arrow to the right three times to actually get to 'now'.

[madb1lly]

Hi @hobinjk, maybe my comment is off-topic for this issue, so tell me if I should raise another.

Rather than the solutions you suggest, why not just have a buffer of two and always check the second against the first; if the second is different from the first then store it. In addition you could add a user-configurable threshold by which the second amount must differ from the first amount before it be recorded.

Where I work we monitor and record lots of real-world data using software called Control System Studio. The sampling modes it can use are described here: http://cs-studio.sourceforge.net/docbook/ch11.html#idm140287028889168. What I described to you above is most similar to the Monitor with Threshold mode.

Like I said, if I should open another issue for this please tell me.

Cheers :)