Bill, thank you for your reply, posting your configuration and updating your wiki! This will be very helpful for all who will use the driver. Thank you!
At the end I figured out the pattern of text string: TIME:0,AMBT:37.73,BARP:1013.48,RHUM:73.44,HUMT:31.07,IRRA:7,BATV:942,PHOV:522,SYST:36.50 To discover the „TIME:0“ and the missing entry in the label map „TIME = dateTime“ took some time and help from this forum! Thanks! My test setup is a Debian Stretch on a VM running weewx with your driver connected to a BananaPi running Armbian and the MQTT broker. As described all works well if I use the command line. I don’t now what happens under the hood using mosquitto_sub -h 192.168.2.143 -v -t weather/# regarding connection, loosing connection, reconnection… Grabbing values wth this command works flawless. But with this setup I see that your weewx looses connection after a while. The question is why there is a timeout?? How to avoid this timeout? weewx log: Sep 25 21:44:44 debian weewx[4084]: wxMesh: Got message TIME:0,temp:21,humi:80 Sep 25 21:44:44 debian weewx[4084]: wxMesh: Working on payload : TIME:0,temp:21,humi:80 Sep 25 21:44:44 debian weewx[4084]: wxMesh: key: TIME value: 1506368684 Sep 25 21:44:44 debian weewx[4084]: wxMesh: key: temp value: 21 Sep 25 21:44:44 debian weewx[4084]: wxMesh: key: humi value: 80 Sep 25 21:44:44 debian weewx[4084]: wxMesh: Sleeping for 1 Sep 25 21:44:45 debian weewx[4084]: wxMesh: Working on payload : Empty Sep 25 21:44:45 debian weewx[4084]: wxMesh: Sleeping for 1 Sep 25 21:44:46 debian weewx[4084]: wxMesh: Working on payload : Empty Sep 25 21:44:46 debian weewx[4084]: wxMesh: Sleeping for 1 Sep 25 21:44:47 debian weewx[4084]: wxMesh: Working on payload : Empty mosquitto log: 1506377517: Client mosqsub/4185-debian has exceeded timeout, disconnecting. 1506377517: Socket error on client mosqsub/4185-debian, disconnecting. 1506377520: New connection from 192.168.2.153 on port 1883. (reconnection only with wxMQTT) As you described your driver doesn’t reconnect. Maybe it’s a problem of the network between the VM and the BananaPi, maybe I should switch from the VM test setup to the system I will run. Then I first have to enable running a second instance of weewx. As it is my productive system with some other tasks running I have to take care! :-D Your driver would fulfill my needs perfekt as I will grab some additional sensors located in the garden. Tom wrote it then would be possible to query this second database of the second weewx from my „main“ weewx instance and include the sensors in the website and plots from my VPII. But as I described: even with the modified wxMQTT driver which reconnects the debug of weewx doesn’t show that data is coming in again into weewx. So something doesn’t work after reconnection to the broker. weewx log after disconnection…no more log entries….: ..... Sep 25 21:53:18 debian weewx[4211]: wxMesh: dateTime 1506369199 Sep 25 21:53:18 debian weewx[4211]: wxMesh: packet content: barometer = 1013 Sep 25 21:53:18 debian weewx[4211]: wxMesh: packet content: Temp = 21 I will check again tomorrow and try to setup a weewx instance on a Raspi (not the VM) and will see whether it changes something (no disconnects?). If I will reach a reliable setup I will grab the sensor data send by an Arduino per serial print (USB connection to the BananaPI) and will publish this sensor values to the broker. As there is a geiger counter connected too straight to the BananaPI per USB which emmitts values to I have different values at different intervals I feed to the broker and hope weewx will put them all together into loop packets. How often does your sensors publish values to the broker? Will keep you informed…thanks for your feedback! Regards, Christian Am Dienstag, 26. September 2017 21:39:01 UTC+2 schrieb Bill Morrow: > > Christian, I wrote the wxMesh driver, and bonjour81 > <https://github.com/bonjour81> improved it with his fork. He changed it > to publish each datum separately, and as you have noticed, reconnect. My > version expects an MQTT publication on the topic "weather" that looks like > this text string: > > > TIME:0,AMBT:37.73,BARP:1013.48,RHUM:73.44,HUMT:31.07,IRRA:7,BATV:942,PHOV:522,SYST:36.50 > > namely key:value pairs with a colon between the key and value, and a comma > between the pairs. The label_map section in wxMesh config maps the keys to > weewx values. My configuration is: > > [wxMesh] > driver = user.wxMesh > > # MQTT specifics > host = localhost # MQTT broker hostname > client = XXXXX > username = XXXXX > password = XXXXX > topic = weather # topic is all weather (indoor and outdoor, > e.g.) > > poll_interval = 1 > > [[label_map]] > TIME = dateTime > HUMT = outTemp > RHUM = outHumidity > INTE = inTemp > INHU = inHumidity > BARP = barometer > IRRA = radiation > PHOV = supplyVoltage > BATV = consBatteryVoltage > AMBT = extraTemp1 > SYST = extraTemp2 > WDIR = windDir > WIND = windSpeed > > Not every publication has to have every possible key. I have an outdoor > station which provides some data, and a separate indoor one which provides > indoor temperature and humidity. The wxMesh driver subscription brings both > in, pushes them in to baseline weewx, which magically combines them into > loop packets. > > Sparse documentation is here > <https://github.com/morrowwm/weewxMQTT/wiki/Configuration>. > > My driver does not attempt to reconnect if it loses the connection to the > MQTT broker. That would be a nice enhancement. I don't have issues with > staying connected on my setup, so this is only an issue when I restart > mosqitto. > > I'm currently spending my free time building hardware (an anemometer right > now), so haven't made improvements to wxMesh a priority. > > I currently use nrf24L01 radios, but plan to switch to rfm69 for increased > range. I could share the station software which reads the radio traffic and > publishes MQTT with you if that would help. >
