Rich with your suggestion, barometer now works, thanks,Gene
On Saturday, August 14, 2021 at 1:39:00 PM UTC-4 bell...@gmail.com wrote:
> In the log should be more info with the error message. I think it might be
> multiple lines, which is why it did not show up in the grep.
>
> But, I think
In the log should be more info with the error message. I think it might be
multiple lines, which is why it did not show up in the grep.
But, I think the problem is that we don’t have the ‘type’ setting in quite
the correct place. Try something like this
[[topics]]
[[[message]]]
Rich, I set up for both json and individual mqtt callback types, the
beginning of my topics section in [MQTTSubscribeDriver] is shown, the
remainder of the topic section is the same as my previous post. I am unable
to get the first topic (homeassistant/sensor/barometer) running as
individual
Phil, I set up for both json and individual mqtt callback types, the
beginning of my topics section in [MQTTSubscribeDriver] is shown, the
remainder of the topic section is the same as my previous post. I am unable
to get the first topic (homeassistant/sensor/barometer) running as
individual
Phil, I set up for both json and individual mqtt callback types, the
beginning of my topics section in [MQTTSubscribeDriver] is shown, the
remainder of the topic section is the same as my previous post. I am unable
to get the first topic (homeassistant/sensor/barometer) running as
individual
Good to hear you have something working.
Here is some information on configuring the message type by payload.
https://github.com/bellrichm/WeeWX-MQTTSubscribe/issues/113#issuecomment-809655246
This exists on the version you have. If you have any feedback, let me know.
rich
On Friday, 13 August
Rich, I have solved problem for persisting distance values without
lightning strikes, I am now using json rather than individual message
callback, this leads to both lightning_strikes and lightning_distance to be
in same loop which as you predicted would solved the problem. My
I am guessing that you are getting loop packets with just distance because
of the order the data is arriving over MQTT.
For example:
message with distance arrives
- data is saved
another message with distance arrives
- packet with saved data is created
- current message is saved
message
You appear to have a logic error in your calibration expression, the
hanging None has no affect at all in your expression. If you wish to check
lightning_strike_count is None you need to use something like:
lightning_distance = None if lightning_strike_count == 0 or
lightning_strike_count
is
Not quite bingo, I am still getting some fixed lightning_distance integers
in the absence of strikes, about 6 per hour. Loops are produced with
lightning_distance = 7.999 and no information on lightning_strike_count
and other loops have with both lightning_distance = 7.999 and
Bingo, fixed by installing v2.1.0-RC MQTTSubscribeDriver. Adding
collect_observations = True and single_queue = True to [[topics], I get
desired behavior. Null lightning distance is recorded in absence of
strikes and with an test simulated lightning strike by battery charger
shorting, I get
I fear the root cause is that MQTTSubscribeDriver takes each MQTT message
and creates a loop packet. This works ok for 'aggregated' messages like
json or keyword (the original implementations). But for 'individual'
payloads that are dependent on each other, it is problematic.I've already
had
I am using weewx-MQTTSubscribe to bring data into Weewx from sensors, so i
don't use SDR sensor map, see config for mqttsubscribe here
https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring A number
of unsuccessful tries to modify mqttsubscribe are commented out.
I am using weewx-MQTTSubscribe to bring data into Weewx from sensors, so i
don't use SDR sensor map, see config for mqttsubscribe here
https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring A number
of unsuccessful tries to modify mqttsubscribe are commented out.
I think going back to your original issue something seems to be off. Can
you post you weewx.conf for lightning data? If you're using sdr, should
contain the following in each section:
[SDR]
[[sensor_map]]
..
lightning_distance = distance..AcuriteLightningPacket
Initially I thought Rich's solution was going to work, adding his suggested
correction 0 else
None> eliminated my fixed lightning_distance data in the absence of
lightning_counts, but it created a new problem, now I don't get
lightning_distance values with a lightning strike. I triggered
I'm no python expert (probably know just enough to be dangerous), but
something like this might get you want you want.
# ligtning_strike_count must exist and have a count > 0 for
lightning_distance to have a valid value
lightning_distance = lightning_distance if 'lightning_strike_count'in
On Tuesday, 10 August 2021 at 08:37:42 UTC+10 gle...@gmail.com wrote:
> Here is my output running weewxd directly, I see three lines which show
> lightning_distance to be None, which is expected from corrections, but the
> following three lines show lightning_distance to be 11.999... It
Yes I added accumulator set at end of weewx.conf and still get the same
result , lightning_distance = 12 for all recorded intervals
Here is my output running weewxd directly, I see three lines which show
lightning_distance to be None, which is expected from corrections, but the
following
is Accumulator set in the weewx.conf ?
at the bottom of my weewx.conf file is like this
[Accumulator]
[[lightning_strike_count]]
extractor = sum
[[lightning_distance]]
extractor = min
merger = minmax
On Monday, August 9, 2021 at 8:11:45 PM UTC+3 gle...@gmail.com
restarts were done with every change of weewx.conf
On Monday, August 9, 2021 at 12:46:33 PM UTC-4 mksm...@gmail.com wrote:
> stop weewx and restart it after you make any change to the weewx.conf
>
> On Monday, August 9, 2021 at 4:57:48 PM UTC+3 gle...@gmail.com wrote:
>
>> Thanks for pointing
stop weewx and restart it after you make any change to the weewx.conf
On Monday, August 9, 2021 at 4:57:48 PM UTC+3 gle...@gmail.com wrote:
> Thanks for pointing me in the right direction, unfortunately your
> suggestion did not fix the persisting 12mile lightning_distance output. I
> tried
Thanks for pointing me in the right direction, unfortunately your
suggestion did not fix the persisting 12mile lightning_distance output. I
tried the following 4 corrections one at a time in weewx.conf:
[[Corrections]]
lightning_distance = lightning_distance if lightning_strike_count > 0
I use this line in weewx.conf and it works ok with seasons skin.. you can
try it
[StdCalibrate]
[[Corrections]]
lightning_distance = lightning_distance if lightning_strike_count >
0 else None
On Sunday, August 8, 2021 at 4:09:43 AM UTC+3 gle...@gmail.com wrote:
> I several
24 matches
Mail list logo
