Error on startup build 4063

[grwkak]

Here are the logs with data and debugging logging turned on. Short period of time.

Guy

[grwkak]

Turns out the entire gauge interface page is not working. At first I thought it was the wind gauges on the dashboard.

Guy

[mcrossley]

The live data seems to be coming in OK, the wind values are changing every packet, the pressure values look reasonable.

Unfortunately, the logging for the Tempest station is quite sparse, so there isn't much more I can see.

You could ask them to try one of the queries Cumulus is sending for the historic data and ask them why it is failing with a status code 2, "DATA_ERROR - null"?

Code: Select all

https://swd.weatherflow.com/swd/rest/observations/device/213434?token=<<token>>&time_start=1733521800&time_end=1733521943

[grwkak]

Thanks - I will ask. Seems to be a more widespread issue and I did let them know that.

Guy

[grwkak]

Just to clarify - is the lack of updates of gauges in the interface also related to this API issue?

Guy

[jokerboy]

I did some debugging on this yesterday (I wrote the original code for the CumulusMX/Tempest integration).

The issue seems to be with the result set being returned via the API, although not necessarily an API issue. The status code being returned is one that isn't expected. We expect either a success (200) or some kind of failure (40x,unauthorized or not found). However it's returning a code of "2" which seems to indicate that there's something wrong with the data, but the data is still returned. There's nothing in the API documentation on this that I could find.

In this case the message is "DATA_ERROR - null", so somewhere in the results there's a record, which could be one of thousands returned, that has a field which has no value.

In my debugging, ignoring this error seemed to work fine and the records appeared to process. The only field I could see that was returned NULL was the serial number of the station, which cumulus doesn't use.

Probably not a good idea to just ignore the error for the inevitable case where a field we use will cause a problem though.

I'll present a fix sometime today or tomorrow which will hopefully work around this issue.

[grwkak]

Thanks! Its odd that it worked fine for so long!

Guy

[southturner]

Hey all,

Just downloaded the latest build 4063 and starting to migrate over to cumulus and seeing this error as well and the other error that is posted in this thread. will continue to watch this thread for more information to be sent out.

looking forward to working with all members.


Matt and Bob

[mcrossley]

I have jokerboy's updated code. It will be in the next build.

[grwkak]

Thanks - updated and the historic data now downloads!

I still have no working gauges and no display of the last Cumulus update time. I'm not sure if there was anything in the diagnostic logs suggesting a cause - did not sound like it.

Guy

[kj6rgx]

I still have no working gauges and no display of the last Cumulus update time. I'm not sure if there was anything in the diagnostic logs suggesting a cause - did not sound like it.

Same here, running 4.3.1 now...

Add: Forgot to mention, the website gauges are okay, it's just the localhost:8998 that displays this anomaly...

[freddie]

If you've done due diligence (i.e. checking integrity with the md5sum utility) then please zip up your MXdiags log file and attach to a reply to this topic. It's hard to do any investigation without log files. Make sure you have debug logging and data logging switched on.

[jokerboy]

I'm actually having the same issue with the gauges not updating.

I've attached the latest log file, but something I noticed that's different between this version and the previous, when I look at the 'Console' in the developer options of the browser (firefox), this error shows up:

Code: Select all

Uncaught TypeError: inp.IndoorHum is null
    convertJson http://172.27.35.61/js/dashboard.js:287
    updateDisplay http://172.27.35.61/js/dashboard.js:233
    onMessage http://172.27.35.61/js/dashboard.js:103
    onmessage http://172.27.35.61/js/dashboard.js:82
    OpenWebSocket http://172.27.35.61/js/dashboard.js:81
    success http://172.27.35.61/js/dashboard.js:351
    jQuery 6
        c
        fireWith
        l
        o
        send
        ajax
    <anonymous> http://172.27.35.61/js/dashboard.js:347
    jQuery 13
        e
        t
        setTimeout handler*Deferred/then/l/<
        c
        fireWith
        fire
        c
        fireWith
        ready
        B
        EventListener.handleEvent*
        <anonymous>
        <anonymous>
dashboard.js:287:13
    convertJson http://172.27.35.61/js/dashboard.js:287
    updateDisplay http://172.27.35.61/js/dashboard.js:233
    onMessage http://172.27.35.61/js/dashboard.js:103
    onmessage http://172.27.35.61/js/dashboard.js:82
    (Async: EventHandlerNonNull)
    OpenWebSocket http://172.27.35.61/js/dashboard.js:81
    success http://172.27.35.61/js/dashboard.js:351
    jQuery 6
        c
        fireWith
        l
        o
    (Async: EventHandlerNonNull)
        send
        ajax
    <anonymous> http://172.27.35.61/js/dashboard.js:347
    jQuery 13
        e
        t
    (Async: setTimeout handler)
        l
        c
        fireWith
        fire
        c
        fireWith
        ready
        B
    (Async: EventListener.handleEvent)
        <anonymous>
        <anonymous>
        <anonymous>

If there's something else I can try to help with this, let me know. Perhaps there's a file I missed during the update. I'm running on a 'Debian GNU/Linux 12' container in Proxmox.

[freddie]

Code: Select all

2024-12-10 04:52:43.210 Debug logging :disabled
2024-12-10 04:52:43.210 Data logging  :disabled

You should switch these two on (debug logging and data logging) before submitting a log file.

interface.png

Have you tried accessing the gauges page in an incognito tab? Perhaps there's some caching happening (or clear your cache).

[jokerboy]

There's an issue with the value of the Indoor Humidity setting being passed to the 'convertJson' function in the file dashboard.js

The value being passed is null, so the following line in that function throws an exception.

inhum: inp.IndoorHum.toString(),

If I comment out that line (//inhum: inp.IndoorHum.toString(),), everything works fine as it did before.

There must have been something that changed in whatever provides the data to that function, a web service or something. I'm guessing that only those stations that don't collect indoor readings, like the Tempest, will see this issue, as it won't be null for others.

Or perhaps the tempest station class isn't providing a default value for that when it should be.