How to actually print loop packets ?

[Conz]

This is driving me bonkers, how do I actually print loop packets ?

I have put 'weewx.engine.StdPrint' at the start of everything under [Engine] [[Services]] but all it is printing is incoming packets from the driver and what they are being mapped to.

.

But want to see the packets from other extensions as well.

I keep running into issues where database fields for extensions (And actually the driver too) aren't being filled and I just can't troubleshoot it properly.

I also want to see what is being sent to the skins for the same reason.

I was using 5.2 but the 5.3.1 update just came through so that's now live.

[Vince Skahan]

Which driver and extension(s) and skin(s) specifically ?   Some log more verbosely if you set debug > 0 in weewx.conf, and weewx itself typically will emit the LOOP data if you run it standalone rather than as a daemon.  Many will log warnings/errors to wherever your weewx logs are set to go to.

[Karen K]

Conz schrieb am Freitag, 6. März 2026 um 19:36:18 UTC+1:

This is driving me bonkers, how do I actually print loop packets ?

I have put 'weewx.engine.StdPrint' at the start of everything under [Engine] [[Services]] but all it is printing is incoming packets from the driver and what they are being mapped to.

I would suggest to have a look at the  weewx-mqtt extension. To use it you would install Mosquitto and some MQTT client. Then you can see all the LOOP packets within that client application. It may additionally provide some history or so.

 

[Conz]

 I am using the customecowitt driver from WernerKr as well as neowx-material from seehase.

For the driver the lightning values are still being weird, but these seem very undocumented as to whats actually in them. And the skins have a hard time seeing the values.

There's also the weewx-skyfield-almanac from roe-dl, which was part of the neowx install, of which i'm trying to add the sun azimuth as well as the moon altitude/azimuth to the DB. (Sun altitude IS in there and IS getting updated) but none of the 3 new values are getting added.

The documentation basically says 'just add the db fields and it should work'

Right now I actually have all skins disabled and I just want the DB to have all the values.

Op vrijdag 6 maart 2026 om 20:13:31 UTC+1 schreef Vince Skahan:

[Conz]

The mqtt was actually a really good suggestion, thanks.  

I actually have that going as part of the neowx skin and it didn't occur to me to watch that.

This makes it a little more interesting, I am seeing values in that stream that are not in the DB

(i hope this paste works lol)

```json
{
"solar": {
"solarAzimuth": 294.569,
"solarAltitude_degree_angle": -23.6877,
"solarTime": 303.218
},

"lunar": {
"lunarAzimuth": 96.6585,
"lunarAltitude_degree_angle": -12.9247,
"lunarTime": 87.4533
},

"lightning": {
"lightning_disturber_count_count": 0.0,
"lightning_num_count": 0.0,
"lightning_strike_count_count": 0.0
},

"battery": {
"ws80_batt_volt": 3.28
},```

The solarAltitude field in the DB has a whack value of  14.something even though somehow the correct math is being done.

Now I feel like the double _count_count values might be causing the skin issues.

But none of the above is actually getting recorded into the db other than the lightning_num_count. Is it just a matter of adding THESE field names to the DB ?

Op vrijdag 6 maart 2026 om 20:54:46 UTC+1 schreef Conz:

[Vince Skahan]

Are you referring to https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin ? 

If so, look at https://github.com/WernerKr/Ecowitt-or-DAVIS-stations-and-Season-skin/blob/main/ecowitt_http/ecowitt_http.py in the area around line 15895 (wow!) for how to test the driver.

Here's an example for Gary's original gw1000 driver with one LOOP message shown:

python3 ~/weewx-data/bin/user/ecowitt_http.py --test-driver --config=ecowitt.conf.http
Using configuration file ecowitt.conf.http

Interrogating GW1200 at 192.168.2.87

2025-10-11 12:18:08 PDT (1760210288): 'dateTime': '1760210288', 'daymaxwind': '2.9012896', 'dewpoint': '10.999999999999998', 'extraHumid1': '54', 'extraHumid2': '55', 'extraHumid3': '58', 'ex
traHumid4': '59', 'extraHumid5': '79', 'extraTemp1': '21.11111111111111', 'extraTemp2': '19.72222222222222', 'extraTemp3': '19.72222222222222', 'extraTemp4': '20.999999999999996', 'extraTemp5
': '14.611111111111109', 'extraTemp9': '12.277777777777779', 'feelslike': '13.499999999999998', 'inHumidity': '54', 'inTemp': '20.72222222222222', 'is_raining': '1', 'outHumidity': '85', 'out
Temp': '13.499999999999998', 'p_rainday': '0.0', 'p_rainevent': '0.0', 'p_rainmonth': '8.889999999999999', 'p_rainrate': '0.508', 'p_rainweek': '1.016', 'p_rainyear': '18.287999999999997', 'p
ressure': '998.9845068508749', 'relbarometer': '998.9845068508749', 'soilMoist1': '52', 't_rainday': '0.0', 't_rainevent': '0.0', 't_rainmonth': '9.398', 't_rainRate': '0.0', 't_rainweek': '0
.508', 't_rainyear': '16.764', 'usUnits': '17', 'vpd': '2.3200000000000003', 'wh26_batt': '1', 'wh26_sig': '3', 'wh51_ch1_batt': '1', 'wh51_ch1_sig': '4', 'wh51_ch1_volt': '1.2', 'windDir': '
57', 'windGust': '0.8985503999999999', 'windSpeed': '0.5990336', 'wn31_ch1_batt': '0', 'wn31_ch1_sig': '4', 'wn31_ch2_batt': '0', 'wn31_ch2_sig': '4', 'wn31_ch3_batt': '0', 'wn31_ch3_sig': '4
', 'wn31_ch4_batt': '0', 'wn31_ch4_sig': '3', 'wn31_ch5_batt': '0', 'wn31_ch5_sig': '4', 'wn34_ch1_batt': '3', 'wn34_ch1_sig': '4', 'wn34_ch1_volt': '1.36', 'ws90_volt': '3.28'

Werner's instructions are so uniquely cryptic and indecipherable (to me) and he refuses to make his stuff installable via the extension installer, so I can't test here. Give it a try.  My guess is you'll need to map some field it emits to a field in the weewx schema in your db.  You might need to set your PYTHONPATH.  See the comments around line 15895 in the file if that's indeed the driver you are using.

[Conz]

That's the driver i'm using yes, it actually installed fine with the extension installer so maybe he saw the light ?

It's also not using the ecowitt_http.py file but the ecowittcustom.py, at least for the intercepting of PWS packets. It might still be using the ecowitt_http for other things but I've not delved into the scripts too deep.

I can get weewx to dump the string from the PWS just fine, it was just that it wasn't actually putting the fields into the db or giving erros with the skins.

But i've had some AI fueled inspiration after Karen's mqtt suggestion and I think I figured it out.

Some values are only in the LIVE data and not in the ARCHIVE.

What i've done now is create my own little custom_obs.py script:

import logging

import weewx
import weewx.engine
import weewx.units

log = logging.getLogger(__name__)


class CustomObsService(weewx.engine.StdService):
    """Register custom observation types so WeeWX can handle/archive them."""

    def __init__(self, engine, config_dict):
        super().__init__(engine, config_dict)

        obs_map = {
            # Skyfield solar/lunar values
            "solarAzimuth": "group_direction",
            "solarAltitude": "group_direction",
            "solarTime": "group_direction",

            "lunarAzimuth": "group_direction",
            "lunarAltitude" : "group_direction",
            "lunarTime": "group_direction",

            # Add any other custom values here
            # "myCustomField": "group_count",
            # "myVoltageField": "group_volt",
            # "myDistanceField": "group_distance",
        }

        for obs_name, group_name in obs_map.items():
            weewx.units.obs_group_dict[obs_name] = group_name

        log.info("CustomObsService registered %d custom observation types", len(obs_map))

I also added the following to [Accumulator] in weewx.conf:

    [[solarAzimuth]]
        extractor = last
    [[solarTime]]
        extractor = last
    [[lunarAzimuth]]
        extractor = last
    [[lunarTime]]
        extractor = last
    [[solarAltitude]]
        extractor = last
    [[lunarAltitude]]
        extractor = last

This should be plenty to figure out the rest for me, and a hint for future enthusiasts who are getting confused.

I'll do some more digging as to why the lightning fields are _count_count but that's a problem for another time.

But the skin lightning error makes total sense if the loop packets are _count_count and not just _count

Thanks for the help and insights :-)

Op vrijdag 6 maart 2026 om 21:26:09 UTC+1 schreef Vince Skahan:

[R]

On Saturday, 7 March 2026 at 04:36:18 UTC+4 Conz wrote:

I have put 'weewx.engine.StdPrint' at the start of everything under [Engine] [[Services]] 

I don't know what you mean by this but if you are going to use StdPrint to display loop packets (and archive records) you really need to understand one thing about how WeeWX services are called - the various entries under [Engine] [[Services]] are processed in order left to right and top to bottom. So if you put StdPrint at the start of the prep_services line you will see loop packets (and archive records if applicable) straight from the driver. Put StdPrint as the first entry of process_services and you will see the same, but put it at the end of the process_services line and you will see loop packets (and driver emitted archive records) after StdConvert, StdCalibrate, StdQC and StdWXCalculate have done their thing to the packet/record. If you are using a driver that only emits loop packets (ie StdArchive creates the archive record) then you won't see any archive records from StdPrint unless StdPrint appears 'after' StdArchive. Think of the [[Services]] entries as an assembly line with loop packets (and driver emitted archive records) going in the front and each service doing their bit to the packets/records. At the end out pops a processed packet/record. Where you put StdPrint on the assembly line determines what StdPrint will produce.

Any services that don't change the loop packet /archive record (eg StdTimeSynce or any of the restful_services) have no effect on the StdPrint output.

Whilst 'moving' StdPrint around can aid in debugging putting multiple StdPrint entries in [[Services]] is probably only going to make for output that is very difficult to read/follow.

R 

[Conz]

Thanks, i forgot where but it said somewhere that the stdprint should be at the start so that's what i've been doing. I'll give this a go to see what happens.

Op zaterdag 7 maart 2026 om 01:42:41 UTC+1 schreef R: