tnx Ikke, I am always in favor of simple and efficient
thanks Ikke,
As a matter of fact that is also how the DS18B20 is read on the raspberry, but as it requires file writes for every reading, I try to stay away from that. Nevertheless, it is an interesting addition.
As for accuracy of the DHT11… I have a couple of “old” ones and compared to some new ones I had bought, they have about a 5 degrees difference (Celsius).
I will all phase them out
/proc isn’t on the SD card so reading and writing to it won’t impact the longevity of the SD card. Everything in Linux is a file and everything in /proc is where the “files” that represent the running processes on your system go.
So unless I’m missing something, you can read and write to the device using the file in proc all day and it won’t be problem.
2 Likes
good to know. Tnx.that helped a lot!!!
I thought the values were stored in ‘sys’
@sihui
thanks for that link.
learn something new every day
For completeness, /dev is the same as /proc only that file system represents the hardware in your machine.
1 Like
Thank you Rich
Most examples I saw for reading the DS18B20 though are writing in the ‘/sys’
hence that I thought they were ‘genuine’ file writes. As in ’ writing to SD’
But that one indeed seems pretty ’ virtual’ as well.
Still lots to learn I guess
1 Like
Absolutely brilliant works like a charm thank you so much for this tutorial just kept it as a DHT22
1 Like
my pleasure
No, when it comes to writing privileges for the world on programs, it doesn’t. Especially when it is about suggesting that to others. Then it is “never, ever” have world write rights.
And if you want to edit the file from other accounts, you should use groups.
It is personal preferences to use octal or symbolic file rights though. I do prefer the logical symbolical, as it can add or remove just the privileges that are relevant. With octal you need to change all (like the = operator in symbolical rights)
The py-file being writeable by world could be the way into your system. 
When replying, especially to a long dormant thread, please quote a little bit of what you are replying to.
That’s a pretty absolute statement. I find that absolute statements particularly in computer security, are suspect.
In this case I assume that it is because of the 0777 on the Python file in the OP.
So what does giving works rwx rights on this Python file do? It means that any user on that machine can open, change, and run that file. It does not mean that the program itself suddenly gets permission to write to all files on the OS(that would only be the case if the root user ran the program which would be a significant vulnerability that someone could use to get in to your system).
That doesn’t sound like a good thing, but wait, an attacker would already have to be on the machine already to exploit that file. And even if they did exploit the file, they can only make the program do things the user that program runs under has permission to do. That’s why we don’t run services as root.
Now a lot of damage can be done by having a services’ program editible by all. But, like I said, the attacker would have to already be on your system. Making the Python file’s permissions more restrictive would not prevent an attacker from getting on your system.
Given this is a single user computer on a network that is not exposed to the internet, your network and this computer has to essentially be pwned befire they can even get at this file.
Is it a best practice to ashtrays use the most restrictive sets of permissions in a DAC system? Yes. Will setting the permissions do anything to protect the computer from being hacked? No. In most home network use cases, it really doesn’t matter.
1 Like
I have problem when I’m trying to start the dht.sh script at boot. It looks like dht.sh is not being opened at the boot. Nothing is being sent by MQTT.
When I type /home/openhabian/dht.sh by myself it works fine.
Hi, thank you all so much for your posts!
I am now struggling to get this running in OH 2.4. I have the MQTT broker
Name: mosquitto
Broker Hostname: localhost
Broker Port: 1883
and the command
./mqtt.dhtsensor.py 'cupboard/temperature1' 'cupboard/humidity1' 4 50
is working great in the command line.
However, I have no idea how to set the connection from the python output to be read and published by MQTT and I’m really trying since a long time.
Could anyone point me into the right directions of how to proceed?
Thanks and best,
Peter
If the topics are broadcasted correctly, then you just have OH subscribe to these topics. Add the mqtt addon (either v1.x or v2.x)and have eg a string subscribe to the topic coming from the script. For setting up mqtt in OH there is a good documentation and a lot of threads in this forum
1 Like