Well, I haven't heard of having to restart WeeWX when the connection is lost, and if that happens I would certainly want to look into fixing that. I'll do some experiments to see if I can recreate.
Sounds like picking the service might be the best long term choice, with the caveat about the reconnect logic needing to be verified. But if you want to get your feet wet, I would suggest that we get it up and running as a driver - perhaps even running from the command line for a bit. The actual configuration work is really the same. So you could migrate to the service as you get more comfortable or after we prove that lost connections are not a problem. The following assumes that you install 1.5.4-rc01. This changed the way to configure MQTTSubscribe. Once installed, there will be three key sections the [MQTTSubscribeDriver]/[MQTTSubscribeService] section. This is the MQTT connection information, and I believe this is pretty straight forward. But after looking at it, if you have questions let me know. Next up is the [[topics]] section. Based on the information you posted, I think this is what you would want [[topics]] [[[weather]]] # The topic you are subscribing to unit_system = METRICWX # Not sure weather you want METRICWX or METRIC. See http://weewx.com/docs/customizing.htm#units [[[[temp_2m]]]] # Name in the MQTT message name = extraTemp1 # WeeWX name [[[[temp_5cm]]]] name = extraTemp2 [[[[temp_dht22]]]] name = inTemp [[[[hum_dht22]]]] name = inHumidity [[[[rain]]]] name = rain [[[[geiger]]]] name = radiation Not sure about your TIME field and the value of 0. I left it out and since it is missing MQTTSubscribe will use the date/time from the server it is running on. There are other options for converting the incoming data, but yours looks pretty straight forward. Last is the [[message_callback]] section. I would call your data 'keyword'. If it was json, I would expect quotes around the fieldnames. So, something like this [[message_callback]] type = keyword keyword_delimiter = "," # The delimiter between the name/value pairs keyword_separator = ":" # The separator between the name and the value There are some additional options when running as a service to attempt to only process data that belongs to the loop packet or archive record that is being augmented. Over time I have found the defaults to be a bit too restrictive, so we might need to configure those a bit. I haven't tried to run a second instance of WeeWX, so I can't help there. But, if you need any more help with MQTTSubscribe, just let me know. -rich On Wednesday, 24 June 2020 12:51:43 UTC-4, Christian Peters wrote: > > Rich, > > that's great. I'm not sure whether I should stay on the driver version or > switch to the service version....which could make it maybe more easy. > But if the MQTTSubscribe as service lost connection and wouldn't > reconnect I have to restart the main weewx prog to get it up again!? So > maybe a second running instance > with MQTTSubscribe is the better choice...? > Difficult...I would perfer one instance as I struggle to get a second > weewx instance up with systemd at the moment.... > > So with mosquitto_sub -h 192.168.1.143 -t weather > > I got this ( in JSON format I think) : > > > TIME:0,radiation:0.17,cpm:31,cps:0,temp_2m:25.97,temp_5cm:27.24,temp_dht22:34.30,hum_dht22:45.30,rain:0.00 > > I mapped in my Python 2 env (weewx2.9, second instance with sql databse) > and wxMesh: > > [[label_map]] > TIME = dateTime > temp_2m = extraTemp1 > temp_5cm = extraTemp2 > temp_dht22 = inTemp > hum_dht22 = inHumidity > rain = rain > geiger = radiation > > So do you know the syntax for the mapping for MQTTSubscribe? > > As I send the data to the MQTT broker by myself it would be maybe best to > use a second instance and tweak the mapping to entrys which are already in > the schema. > So I could stay in the mapping posted above? > > Do you set up a second instance of weewx with systemd already...? > Any help or syntax examples would be welcome, especially for the format of > the label mapping of > MQTTSubscribe. I tried weew-multi but dont get the second instance up... > Not sure its systemd ready... > > Thanks in advance, > > Christian > > > > Am Mittwoch, 24. Juni 2020 16:12:12 UTC+2 schrieb Rich Bell: >> >> Christian, >> >> MQTTSubscribe should be able to meet your needs. I know the documentation >> is a bit sparse, but I can help get you up and running. >> >> The first question you need to answer is whether to run as a service or >> driver? From what I am understanding. If you ran as a driver it would >> essentially be a replacement for wxmesh. Meaning it would the database >> configured for that WeeWX instance. If you ran MQTTSubscribe as a service, >> you could augment the data in your other WeeWX instance. >> >> The next question is the format of the incoming data. Is it json, keyword >> (name=value), or individual (single observation per topic)? Lastly, what >> name mapping do you need to? >> >> -rich >> >> On Wednesday, 24 June 2020 08:59:25 UTC-4, Christian Peters wrote: >>> >>> Hi, >>> >>> I ran a weewx 3.9. station with Python 2 and a seperate weewx instance >>> with the wxMesh.py driver. >>> This works very nice (as far as the broker isn't down or the connection >>> breaks - then a restart of the weewx instance which holds the wxMesh driver >>> is needed...!). >>> As I now switch to Python 3 and weewx 4.x I figured out that the >>> wxMesh.py driver isn't Python 3 ready? :-( >>> >>> How can I catch MQTT data into the weewx database from an external >>> broker ilocated n my home lan? >>> >>> Is this the right extension to use: >>> >>> https://github.com/bellrichm/WeeWX-MQTTSubscribe >>> ....? >>> >>> What I don't understand: if I will use it as a sevice, in which database >>> will it put my values? >>> Is there a mapping needed!? Can I use a seperate database? >>> Is there a configuration example available or does anybody set up such a >>> station and could provide the config or give me some advice >>> howto get the data form the MQTT broker into weewx and the database to >>> show the values and graphs!? >>> That would be great! >>> >>> Thanks in advance! >>> >>> Regards, >>> >>> Christian >>> >> -- 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/9be42847-5722-485b-abc9-c98a7f8081edo%40googlegroups.com.
