Hi Rich, thanks a lot for your reply. Great explanation. I will test with loop sending, and wait the alpha code will be beta.
Regards Christian [email protected] schrieb am Sonntag, 7. März 2021 um 16:33:47 UTC+1: > Christian, > You have a few options that I know of, each with its pros and cons. > 1. Publish on each loop packet (Note, not on both archive and loop). In > this scenario, MQTTSubscribeDriver will generate loop packets and from > these WeeWX will create an archive record. In theory this should.match the > archive records of your remote location. But, if for some reason some MQTT > payload goes missing, there could be discrepancies. > 2. Publish on the archive record. As you noted, there will be time lag of > your archive interval. But the archive data will match and if some data > does not arrive, you can export the remote data and import it. > 3. If you want to live on the edge.... There is a fork of Matthew’s > weewx-mqtt that publishes loop and archive data on separate topics. It can > be found here, https://github.com/moonpyk/weewx-mqtt. With this you could > use MQTTSubscribeDriver’s alpha/experimental option, archive_topic. With > this set, MQTTSubscribeDriver will create loop packet’s from the loop > topic. But when it is time to create an archive record, it will pull the > data from the archive topic. I have this running in a very controlled > environment. I have no idea how it would ‘hold up’ in the real world where > messages might go missing, be delayed, etc. And again, it is alpha code - > so use at your risk. > - rich > > On Sunday, 7 March 2021 at 08:25:19 UTC-5 [email protected] wrote: > >> Now I have one more Question. >> >> On the sender Site I have this Config now: >> >> [[MQTT]] >> >> server_url = xxxxx >> >> topic = weather >> >> unit_system = METRIC >> >> binding = loop, archive >> >> aggregation = aggregate >> >> append_units_label = false >> So I sent loop and archive. >> Both will sent as "loop". >> >> In this case the receiver show the same Data, with the same Time. >> >> If I have the binding only "archive" the receiver is 5 Minutes back. >> >> Which is the right config for me? >> >> Regards >> Christian >> >> Christian Radermacher schrieb am Freitag, 5. März 2021 um 17:54:34 UTC+1: >> >>> >>> Now everything is working fine, I have no idea, why the Skin would not >>> generate. >>> I will play around, an come back with other questions, if necessary. >>> >>> Thanks to all, helped me >>> >>> Regards >>> Christian >>> Christian Radermacher schrieb am Freitag, 5. März 2021 um 17:40:19 UTC+1: >>> >>>> Hi Rich, >>>> >>>> thanks for the reply. Now I can see that it is working, but my Skin >>>> would not be generated. So I search another error. >>>> >>>> Regards >>>> Christian >>>> >>>> [email protected] schrieb am Freitag, 5. März 2021 um 16:18:42 UTC+1: >>>> >>>>> Thinking more, I am pretty sure the alpha code won’t work for you. >>>>> - rich >>>>> >>>>> On Friday, 5 March 2021 at 09:58:38 UTC-5 [email protected] wrote: >>>>> >>>>>> Christian, >>>>>> I’d recommend adding ‘append_units_label = False’ on the publish >>>>>> side. This will stop the appending of units to the label and you won’t >>>>>> have >>>>>> to rename them on the subscribing side. >>>>>> >>>>>> I’d expect the subscribing config to look something like this. >>>>>> >>>>>> [MQTTSubscribeDriver] >>>>>> driver = user.MQTTSubscribe >>>>>> >>>>>> host = >>>>>> >>>>>> [[message_callback]] >>>>>> type = json >>>>>> >>>>>> [[topics]] >>>>>> unit_system = METRIC >>>>>> [[[weather/loop]]] >>>>>> >>>>>> If you post the log from startup through one archive period, I could >>>>>> dig deeper. >>>>>> >>>>>> Important note, with the set up above, I believe you are publishing >>>>>> archive records. These are received and put into loop packets by >>>>>> MQTTSubscribe. WeeWX would then create archive records out of them. I >>>>>> think >>>>>> this should all work, but there might be some timing issues. The log >>>>>> would >>>>>> show what is going on. >>>>>> I do have alpha/experimental code that would receive the MQTT payload >>>>>> and process it as an archive record. It would very much be “use at your >>>>>> own >>>>>> risk”. >>>>>> - rich >>>>>> >>>>>> On Friday, 5 March 2021 at 09:05:50 UTC-5 [email protected] >>>>>> wrote: >>>>>> >>>>>>> ok, i installed the receiver Weewx new from scratch. No it seems to >>>>>>> work without errors. >>>>>>> I See in the (debugLevel 2) the incoming MQTTValues. But they don't >>>>>>> where displayed in the screen. It seems, there is one point missing. >>>>>>> >>>>>>> Regards >>>>>>> Christian >>>>>>> >>>>>>> [email protected] schrieb am Freitag, 5. März 2021 um 14:32:15 >>>>>>> UTC+1: >>>>>>> >>>>>>>> a driver creates the original packet with a timestamp, a service >>>>>>>> changes (usually adds to) the existing packet. >>>>>>>> some modules, like gw1000, can be configured to be in either mode >>>>>>>> (i.e. originate packets, or augment existing packets produced by some >>>>>>>> other >>>>>>>> driver). i do this, with vantage as driver and gw1000 in service mode >>>>>>>> >>>>>>>> On 5 Mar 2021, at 10:59 pm, Christian Radermacher < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> In which case I user Service, in which case I use driver? >>>>>>>> >>>>>>>> >>>>>>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/93b4482f-9766-4f45-8398-0585d94fbbe7n%40googlegroups.com.
