count_over_time({host=~”$host”, job=”syslog”} [$__interval] |~ “$free_form_filter” |~ “$filter”)

I do see all my host on the Log Line Counts By Host (Unfiltered). i also see Logs By Host on the bottom panel.

Thoughts?

@version: 3.29
@include “scl.conf”

source s_local {
internal();
};

source s_network {
default-network-drivers(
);
};

destination d_loki {
syslog(“promtail” transport(“tcp”) port(“1514”));
};

log {
source(s_local);
source(s_network);
destination(d_loki);
};

Fred – you’re absolutely right – a typo in those up/down/stop scripts. As for the logs – are you talking about the JSON logs that are stored in Loki or a different one? I’m actually rebuilding the All In One now that I’ve added forecasts to it. With that effort, I’ve added better debug/info logging in general to the collectors.

The stop.sh and down.sh scripts appear to be the same. For stop.sh, shouldn’t the last line read docker-compose stop instead of docker-compose down?

How do I decrease the log level for the json.logs? Have one that grows quite large day by day. I believe the log level is set to info, but am unsure which configuration file might set it to warn or perhaps stop logging altogether.

Nice! Do you have Tempest or the Air & Sky? I just made updates to allow both to be seen. Like literally a few minutes ago. You can see the changes in v1.03 or you can grab the individual dashboard files. You can see the two files here: https://github.com/lux4rd0/weatherflow-dashboards-aio/tree/main/config/grafana/dashboards/weatherflow. If you do have a Tempest and it’s still not showing – certainly get back with me and we’ll troubleshoot it.

The odd thing now is that I see device detail data, the RSSI and battery voltage graph is filling out as is the status for the hub and Tempest, but all other dashboards are blank with a simple ‘No data found in response’… My guess? WeatherFlow changed the UDP data format at some stage/firmware version and so the data collector is not seeing my data.

Hello! And thanks for spending some time trying to make this work. My hope was that for most, simply running the docker-compose and/or up.sh commands would just “work”. But what I’ve seen is the permissions for running the containers tend to get messy. What I suspect is that Loki is trying to start up but doesn’t like the permissions where the data files are being created and/or written. If you start the script up without the proper UID/GID the first time – that /data/loki gets created as root or doesn’t get created at all. You may need to manually change the docker-compose.yml file to reflect the actual numbers of the user ID that you’re running as. The “WARNING: The UID_GID variable is not set” would explain some of those errors. In the Loki stanza in the docker-compose.yml, can you change the user: "${UID_GID}" to something like user: "0:0" (if you’re root) or whatever you actual user/group permissions on the file system are? Can you also share what OS/system you’re trying to run it on? You can also (for sake of testing) comment out the " - ./data/loki:/tmp/loki:rw" and user to see if Loki starts up. I have that volume mount external to the container so that you don’t lose the data if you “down” the container. Lastly – thanks for the 50022/50222 typo. I updated it!