Version 1.2.0 is now available here,
https://github.com/bellrichm/WeeWX-MQTTSubscribe/releases/tag/v1.2.0 It
provides options to ‘loosen’ the checks that the MQTT payload ‘belongs’ to the
packet timespan.
Rich
--
You received this message because you are subscribed to the Google Groups
"weewx
Since I was already handling payloads with missing datetimes, option 4 was
easier for me to get my head around. A new [[Topic]] option, use_server_time
has been added. When set to True, the datetime in the MQTT
payload is ignored. The default is False. Beta code can be found in this
branch, http
Rich,
Option 4 and 5 seem like a good approach.
I am a big advocate for using MQTT for sensor and control in home
automation but this is a good example of some of challenges. I was
thinking about adding many more parameters to the weewx database but the
present latency is too high. I know we
Patrick,
Good sleuthing. I see a few options.
1. Use the overlap option. This is why I added it. Looking at your log, you
would need it to be greater than 2. This would push the interval back to
something like, 1561436115.x and therefore the data with a timestamp of
1561436116 would be included.
I see what's happening. The packets are published:
[image: temp.PNG]
But they are not seen by weewx until:
Jun 24 21:15:20 MITX-6930 weewx[26106]: MQTTSubscribe:
MessageCallbackProvider For sensor/bathroom/Temperature has QOS of 0 and
retain of 0 received: {"dateTime":1561436116.0,"extraTemp1"
I downloaded it again from github and it's running OK. I am doing some
testing now.
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@google
Patrick,
I’m not sure what is happening. I downloaded the file it compares to the one I
am running. I’ll do some more digging tomorrow. I’m not expecting any
different results, but you could try downloading from the master branch in git.
- Rich
--
You received this message because you are subs
Ok,
I reinstalled the extension and here is what's happening:
Jun 24 15:06:28 MITX-6930 systemd[1]: Starting LSB: weewx weather system...
Jun 24 15:06:28 MITX-6930 weewx[24692]: * Starting weewx weather system
weewx
Jun 24 15:06:28 MITX-6930 weewx[24704]: engine: Initializing weewx version
3.9.
Thanks I am replacing the file now.
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web vis
Patrick,
I'm not sure what is going on. Could you try the attached? It should log
some additional information about the queue
Thanks. - Rich
On Monday, 24 June 2019 01:20:35 UTC-4, Patrick Mendiuk wrote:
>
> The original topic has been queued and processed without issue for over 24
> hours. I a
The original topic has been queued and processed without issue for over 24
hours. I added some other topics that are queued but never processed:
Jun 23 21:51:08 MITX-6930 weewx[8383]: MQTTSubscribeService: Queue was empty
Jun 23 21:51:08 MITX-6930 weewx[8383]: MQTTSubscribeService: Packet after
The original topic is being queued and processed fine. I have some other
topics that are being queued but never added:
Jun 23 21:51:08 MITX-6930 weewx[8383]: MQTTSubscribeService: Queue was empty
Jun 23 21:51:08 MITX-6930 weewx[8383]: MQTTSubscribeService: Packet after
update is: 2019-06-23 21:
>
> The original data topic is being queued and processed fine by
> mqttsubcribe. I have other MQTT packets that are added to the queue but
> are ignored:
>
Jun 23 21:51:08 MITX-6930 weewx[8383]: MQTTSubscribeService: Queue was empty
Jun 23 21:51:08 MITX-6930 weewx[8383]: MQTTSubscribeService
The new version has been working without issue. Thanks very much for all
your effort and a great weewx extension.
-Patrick
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send a
Version 1.1.3 is now available. When running as a service, this update
“ignores” packets that have a datetime prior to the last packet’s datetime that
it updated. Meaning these “old” packets are not updated with the MQTT data. The
next packet that has a datetime greater than the last packet upda
Patrick,
I don’t think I was clear. The driver that you are using is emitting
packets that say the data is in the units METRICWX. Because a packet has to
have a consistent unit, MQTTSubscribe converts the data to match the units
that the driver is emitting and then updates the packet.
Further in th
I don't know where that is coming from. Here is the whole packet:
sensor/living_room/TH {"dateTime":1561146975.0,"inTemp":72.9,"inHumidity":
51.8}
I will wait for your update and add a unit value pair to the payload.
-Patrick
>
--
You received this message because you are subscribed to th
I don't know where that unit designation is coming from:
sensor/living_room/TH {"dateTime":1561146975.0,"inTemp":72.9,"inHumidity":
51.8}
I will wait for your update and then add unit value pair to the payload.
-Patrick
On Thursday, June 20, 2019 at 11:32:30 AM UTC-7, Patrick Mendiuk wrote:
>
>
I don't have any unit value pair in the MQTT payload.
sensor/living_room/TH {"dateTime":1561146975.0,"inTemp":72.9,"inHumidity":
51.8}
I don't know where that's coming from. I will wait for your update and
then add a unit value pair.
-Patrick
On Thursday, June 20, 2019 at 11:32:30 AM UTC-7,
Thanks for the info. My plan is to ignore packets that have “time traveled into
the past” and update the next packet that has a current datetime with the MQTT
data.
In regards to the temperature, if needed, the data coming via MQTTis converted
to match the units of the packet. You have specified
I am running the current version from github. Here is my configuration:
# Options for extension 'MQTTSubscribe'
[MQTTSubscribeService]
# This section is for the MQTTSubscribe service.
# Turn the service on and off.
# Default is: true
# Only used by the service.
enable = t
I don't know much about MQTTSubscribe, and I may not be onto anything, but
what do you have set for your overlap setting?
On Thursday, June 20, 2019 at 2:32:30 PM UTC-4, Patrick Mendiuk wrote:
>
> I am trying to setup Weewx 3.9.1 with WeatherflowUDP, MQTTSubscribe, MQTT
> and the Belchertown 1.0
22 matches
Mail list logo
