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. 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>.
Also, 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.
On Monday, 25 September 2017 19:22:27 UTC-3, Christian Peters wrote:
>
> Hm...wxMesh and even a python test script using paho.mqtt lost connection
> from time to time.
> But the python demo script reconnects while wxMesh seems not to reconnect
> so the empty payload starts and didn't recover. wxMQTT seems to
> reconnect...but it anyway stops after a while grabbing data.....(IP ....153
> (debian))!
>
> 1506377499: New client connected from 192.168.2.153 as weewx_mqttc (c1,
> k60, u'default_usernameXXX').
> 1506377506: New connection from 192.168.2.143 on port 1883.
> 1506377506: New client connected from 192.168.2.143 as mosqpub|7457-balin
> (c1, k60).
> 1506377506: Client mosqpub|7457-balin disconnected.
> 1506377506: New connection from 192.168.2.143 on port 1883.
> 1506377506: New client connected from 192.168.2.143 as mosqpub|7459-balin
> (c1, k60).
> 1506377506: Client mosqpub|7459-balin disconnected.
> 1506377516: New connection from 192.168.2.143 on port 1883.
> 1506377516: New client connected from 192.168.2.143 as mosqpub|7462-balin
> (c1, k60).
> 1506377516: Client mosqpub|7462-balin disconnected.
> 1506377516: New connection from 192.168.2.143 on port 1883.
> 1506377516: New client connected from 192.168.2.143 as mosqpub|7464-balin
> (c1, k60).
> 1506377516: Client mosqpub|7464-balin disconnected.
> 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.
>
> Sadly I'm not able to fix this....maybe someone will read this and maybe
> have a look on the wexMesh/wxMQQT driver....
>
> In the thread Neil posted there was a hint that we have to take care that
> if the connection is lost to the broker the driver has to reconnect...but
> this seems not to be working inside weewx?
>
> Regards,
>
> Christian
>
>
>
>
>
