Hmmm, 1605042630 is 30 seconds past the top of the minute, considering WeeWX works with whole minute archive periods I think you may treading on some uncertain ground. Adding data to the archive directly can be a risky process, far better to add the data to the loop packet/archive record before the archive record is saved to database and let WeeWX take care of interacting with the database. That way WeeWX takes care of all the database housekeeping (eg updating daily summaries).
Gary On Wednesday, 11 November 2020 at 07:17:33 UTC+10 axelle....@gmail.com wrote: > I wrote a script that gets the external temperature from the MQTT message > and add its to the weewx database (./archive/weewx.sdb) : I compute the > right epoch time and update the "outTemp" column. > > For example, below you see the temperature of 12.7: > > sqlite> select * from archive where dateTime >= 1605042600; > 1605042630|16|10|||||12.7|||||||||||||||||||||||||||||||||||||||||||| > > However, strangely, the value does not reflect on the website, even after > waiting the 10 minutes refresh time (the website is not refreshed all the > time), where yesterday I got it working and saw a value. > > Is there a reason why this strategy might not be working? > > Axelle. > > On Sunday, November 8, 2020 at 7:59:11 PM UTC+1 bell...@gmail.com wrote: > >> The [[[topic1]]], etc. are the different MQTT topics that you are >> publishing to. >> I think if you run MQTTSubscribe as a service, when it augments either >> the loop packet or archive record, it will over write any data that has >> been populated by the driver. But, I have not tested this behavior. >> rich >> >> On Sunday, 8 November 2020 at 12:59:29 UTC-5 axelle....@gmail.com wrote: >> >>> >> - https://github.com/bellrichm/WeeWX-MQTTSubscribe >>> >That takes data from mqtt and treats it like a sensor in weewx. >>> >>> Okay, so it's rather this one I need. >>> >>> >weewx has a concept of driver and service. I think you will have to >>> >pehaps modify the WMR200 driver to behave as if temp is not there, and >>> >run mqttsubscribe as a service to inject temperature from your Wemo. >>> >>> Yes that's the idea. Still use WMR200 driver, but add mqttsubscribe as a >>> service. >>> The documentation for MQTTSubscribe gives a short example for the >>> service (see below). I understand where the Engine part goes. But I am not >>> sure what "topic1" is ? >>> >>> >>> [MQTTSubscribeService] >>> host = localhost >>> payload_type = json >>> [[topics]] >>> [[[topic1]]] >>> [[[topic2]]] >>> [Engine] >>> [[Services]] data_services = user.MQTTSubscribe.MQTTSubscribeService >>> >>> >>> On Sunday, November 8, 2020 at 5:53:55 PM UTC+1 Greg Troxel wrote: >>> >>>> >>>> Invisible Man <axelle....@gmail.com> writes: >>>> >>>> > The external temperature of my WMR200 is failing, and it's apparently >>>> > difficult to find a replacement. So, I'm using a temperature sensor I >>>> did >>>> > myself (based on a Wemo + DS18B20 sensor) which sends the temperature >>>> to a >>>> > MQTT broker (a Raspberry Pi). >>>> > >>>> > I've seen at least 2 different projects to use MQTT with Weewx : >>>> > >>>> > - https://github.com/morrowwm/weewxMQTT >>>> >>>> That publishes data from weewx to mqtt. >>>> >>>> > - https://github.com/bellrichm/WeeWX-MQTTSubscribe >>>> >>>> That takes data from mqtt and treats it like a sensor in weewx. >>>> >>>> > Is there a preferred way? Also, I am going to have some data coming >>>> from >>>> > WMR200 (rain, wind...), and some other coming from MQTT >>>> (temperature). I >>>> > don't think weewx supports several drivers, does it ? So it means >>>> I'll keep >>>> > using wmr200 driver and use something to insert only temperature from >>>> MQTT. >>>> >>>> weewx has a concept of driver and service. I think you will have to >>>> pehaps modify the WMR200 driver to behave as if temp is not there, and >>>> run mqttsubscribe as a service to inject temperature from your Wemo. >>>> >>>> This is from a big picture viewpoint not so strange, but it is strange >>>> in that outside temperature is arguably the primary reading from a >>>> station, so not having that is very odd. Therefore I would not be >>>> surprised to find a baked-in assumption about that which needs to be >>>> overridden. >>>> >>> -- 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 visit https://groups.google.com/d/msgid/weewx-user/c0a36e5b-db3e-46b6-b0e9-4004f976c038n%40googlegroups.com.
