Hardware: Raspberry 3, DS2481, DS2408 based roller shutters, DS1820s
OS: raspbian
Java Runtime Environment: provided with raspbian
openHAB version: 2.4
Over the last months the reliability of my onewire installation degraded. Most annoying problem is/was that after some idle time the system did not react to the first click on the roller shutter in basic ui. There are the respective entries in the logs but not reaction by the roller shutter controllers. In the last weeks I found time to analyze the problems and found the following:
Faulty wiring from my side: Place the 1wire cable away from mains wires as far as possible. Restricted space is no excuse. You cant fool physics ;-).
Ground your cable shields. One of my roller shutter motor is now so noisy that it confuses my DS2481 in a way I had to power cylcle it to make it work again after the motor starts.
Then I analyzed the first mention problem in more detail: The problem exists if I use the onewire binding (I have a special bugfix version provided here some months ago) or if I use the exec binding and call the 1wire command line tools from the exec binding. There is no problem when I call the onewire command line tools directly from my rules (executeCommandLine()) or if I control the owfs server outside from openhab from a self written java client. This makes me think that something in the openhab binding architecture looses my commands? Looking at the openhab logs I can’t tell a difference between the two methods.
Anyone here who wants to assist in further debugging this?
As an old duffer, I am constantly amazed anyone gets onewire working over more than a metre. It was never intended for that … mind you ethernet was never intended for gigabit speeds either.
Old duffer’s tip - ground cable shields at one end only. It’s to stop current flowing through the shield where two remote “grounds” are not necessarily at the same potential.
Ground e.g a motor casing is not necessarily anything to do with control electronics “0 volts” and you should keep connections separate.
There are “good practice” guides on the web about onewire physical topology - daisy-chain, star, etc. - that might be worth reviewing.
Goes a long way to explaining a deterioration over time.
This would be very interesting to work out. I would suspect timing more than anything. Can you show us comparable details?
For completeness I forgot to mention that also a bunch of broken DS1820s made me think me onewire bus(es) are unstable. They randomly reported negative temperatures (starting with -85° so this made me firs think about the +85 which could mean to little power, I do not use parasitic power) but also other values down to -127°. After replacing them with good ones the problem with negative temperature reading was solved.
Already did it on one side only.
That’s separate
I tried everything in the " Guidelines for Reliable Long Line 1-Wire Networks" but nothing helped. It only got better after I moved the onewire line away from the mains lines of the motors and grounded the shielding
To clarify: Currently my onewire buses are stable and work reliably as long as I do not use the onewire or exec binding in openhab.
Unstable
After a pause or every now end then the command looks like being executed from looking at the logs
but the onewire motor controller does not react:
a) onewire binding
Thing digitalio2 X3A718F1C000000 [
id="3A.718F1C000000",
refresh=300
] {
Channels:
Type dio : digital0 [
mode="output"
]
Type dio : digital1 [
mode="output"
]
}
Number rs_1f_south_lw_PIOB "" { channel="onewire:digitalio2:rs:X3A718F1C000000:digital1" }
The shell script calls owwrite
b) owfs common line tools, e.g /usr/bin/owwrite /3A.A06C26000000/PIO.BYTE 1 from outside openhab
c) self written java client to send commands to the motor controllers outside from obenhab
