To answer your question: Yes and no. The configuration is text-only, but if you’ve followed the docker-compose.yml you should see a share wmbusmeters_data if you open the samba share via smb://192.168.0.xxx.
If this helps, here are my notes and my config files (as said, done ~ 2 years ago). Let me know if this helps. I might find some time to write a more complete / nicer tutorial.
Work either via Terminal (docker exec -it wmbusmeters /bin/sh) or via the Samba share (smb://192.168.0.150/wmbusmeters_data/logs)
Show what’s coming in already via tail -f /wmbusmeters_data/logs/wmbusmeters.log
Create one file per meter in smb://192.168.0.150/wmbusmeters_data/etc/wmbusmeters.d/nameyourmeter with a text file such as…
… that specifies the meter that should be captured.
3. Configure the config file smb://192.168.0.150/wmbusmeters_data/etc/wmbusmeters.conf
# Define Loglevel
# loglevel=debug
loglevel=normal
# Device setting
device=auto:t1,c1
# Following line solves detection problem of AMB8465 on Raspi, see https://github.com/weetmuts/wmbusmeters/issues/336
donotprobe=/dev/ttyAMA0
# device=rtlwmbus(ppm=17) <- This is the line for the Nooelec NESDR stick
# Listento depending on used device (AMB8465 or Nooelec NESDR stick)
listento=c1,t1
# listento=c1,t1,s1 <- This is the line for the Nooelec NESDR stick
# Loglevel
# logtelegrams=true
logtelegrams=false
format=json
# Deactivate the following two lines to reduce logging to protect Raspi SD Card
# meterfiles=/wmbusmeters_data/logs/meter_readings
# meterfilesaction=overwrite
# Logging settings
logfile=/wmbusmeters_data/logs/wmbusmeters.log
meterfilesnaming=name
meterfilestimestamp=day
alarmtimeout=1h
alarmexpectedactivity=mon-sun(00-23)
# ignoreduplicates=false
ignoreduplicates=true
shell=/usr/bin/mosquitto_pub -h mqtt -u <username> -P <password> -i wmbusmeter -t wmbusmeters/readings/$METER_ID -m "$METER_JSON"
alarmshell=/usr/bin/mosquitto_pub -h mqtt -u <username> -P <password> -i wmbusmeter -t wmbusmeters/alarm -m "$ALARM_TYPE $ALARM_MESSAGE"
Thank you for your angelic patience and detailed instructions.
I feel that I am very close, but despite many attempts and several hours of searching on the Internet, I still haven’t achieved my goal, which is why I came back with three questions:
1.No meters configured.
So far I’ve been able to access the wmbusmeters_data directory by adding a network location in windows.
I pasted your configuration file then created in windows 5 notepad files with the numbers of meters that my nanocul finds, removed the .txt extension and pasted straight into the directory etc/wmbusmeters.d
After each change in the conf file and meter files, I entered Stacks and restarted the wmbusmeters container.
Unfortunately, it appears in the wmbusmeters.log file after restart
Started config cul on /dev/ttyUSB0 listening on t1
No meters configured. Printing id:s of all telegrams heard!
And then first telegram looks like:
Received telegram from: 70611766
manufacturer: (TCH) Techem Service (0x5068)
type: Cold water (0x72)
ver: 0x74
device: cul
rssi: -61 dBm
driver: mkradio3
I do not understand why, since I have uploaded the cold1766 file
in which it is entered:
name=cold70611766
id=70611766
driver=mkradio3
I tried different combinations to make the filename identical to the name parameter inside the file, and also to make them different - no result. What this is about?
The second thing, in the case of configuration made according to the first post, does mosquitto require additional configuration in order to work? I see a running mosquitto container in portainer BUT I can’t log in with MQTTExplorer(windows mqtt client) at 192.168.x.x:1883. From what I can see we didn’t restrict access to mosquitto via the .env file so why can’t I connect?
The third thing: can you write about the updates in Docker by the way?
While using openhabian you go to openhabian-config and select “02Upgrade system”. What will our updates look like when OH3.5 or other new containers are released?
Will there be a notification about a new version somewhere in the portainar or should we track new software releases ourselves? What about updates to portainer and docker itself?
To come back to this / your last question (just tried to restore my own system as a test and also had problems with wmbusmeters, since no configuration was being taken despite being set): I had a bug in the volume-definition of the wmbusmeters volumes, which I fixed in the stack-definition above.
Please re-deploy from the stack above. What you did sounded correct and should work now.
> rpi4g@raspberrypi:~ $ sudo nano /etc/dphys-swapfile
> GNU nano 5.4 /etc/dphys-swapfile *
> # /etc/dphys-swapfile - user settings for dphys-swapfile package
> # author Neil Franklin, last modification 2010.05.05
> # copyright ETH Zuerich Physics Departement
> # use under either modified/non-advertising BSD or GPL license
>
> # this file is sourced with . so full normal sh syntax applies
>
> # the default settings are added as commented out CONF_*=* lines
>
>
> # where we want the swapfile to be, this is the default
> #CONF_SWAPFILE=/var/swap
>
> # set size to absolute value, leaving empty (default) then uses computed value
> # you most likely don't want this, unless you have an special disk situation
> CONF_SWAPSIZE=100
>
> # set size to computed value, this times RAM size, dynamically adapts,
> # guarantees that there is enough swap without wasting disk space on excess
> #CONF_SWAPFACTOR=2
>
> # restrict size (computed and absolute!) to maximally this limit
> # can be set to empty for no limit, but beware of filled partitions!
> # this is/was a (outdated?) 32bit kernel limit (in MBytes), do not overrun it
> # but is also sensible on 64bit to prevent filling /var or even / partition
> #CONF_MAXSWAP=2048
Hi cplant, I tried redeploy and it doesnt help so today I tried the installation completely again from the scrtach and following the instructions from first post. Unfortunately in the case of wmbusmeter I still get information in the wmbusmeters.log file that No meters configured…
Maybe I should create these configuration files with sudo nano and not with windows notepad?
Sry for delay. First of all: Telegrams are received (which is the tricky part), so it’s “just” about filtering and decrypting the right ones.
Two ideas:
Yep, was also thinking about going the sudo nano-path as well, to make sure it’s not some “Windows-Notepad-problem”.
To make sure that the samba shares don’t point to a directory where wmbusmeters can’t see it (bug in my share-definition), maybe do the configuration in the container itself (docker exec -it wmbusmeters /bin/sh).
To be fair, this was the only part which I did not test on my system because, as said, wmbusmeters is running without problems for some time now.
I tried, among other things, to upload the meter files directly to the /etc directory next to wmbusmeters.conf, but nothing changed - the .log file still indicates “No meters configured”
however, after applying the second code, I lost access to the wmbusmeters_data directory in windows - probably due to further connections of this line of code with other lines to duplicati and to samba stack.