Closed danielkarg closed 3 years ago
Hi, thats odd.
So you did train them correctly and you get feedback from the shutters once trained?
Did you try to move all channels at once using --channel 15
or a single one?
Hi,
Unfortunately it took a while until the error occurred again.
All three shutters have been trained correctly. I've been using the stick for over a year. Last year as a slave with the "TRAIN" method, this year as a "TRAINMASTER" to isolate errors. With both methods, the error occurs about every 10th time on different shutters.
Last night I saw that one shutter was not going down controlled by a cron job. The manual control over the ssh terminal did not help. Channel 15 didn't work, too. After several actuations it worked at some point. All three shutters where then down.
Then I moved up all of them via channel 15. This worked. Then I moved them all down via channel 15 and again one of the shutters didn't go down.
It is not always the same shutter.
Do you have another tip what it could be?
MANY THANKS!
I think that sounds more like a signal think... Have you configured all shutters on one unit?
Feel free to post the stats, so we know which unit is used.
./centronic-stick.py -s
code increment (hex) configured last run 1737b 410 (0x019A) 1 2021-02-07 18:29 1737c 0 (0x0000) 0 (unknown) 1737d 0 (0x0000) 0 (unknown) 1737e 0 (0x0000) 0 (unknown) 1737f 0 (0x0000) 0 (unknown)
I have configured the shutters only with --channels 1,2,3
I also think that it sounds more like a signal problem, but the distance between shutters and USB stick is only two till three meters. However, there are cases in which the two shutters with the furthest distance works and the nearest shutter doesn't work.
One more note about my configuration. I am running on an Intel NUC VMWare ESXi. A Debian VM runs on this. An active USB cable with a length of 20m connected the NUC with the USB stick.
I had already considered whether it might be something like a baud rate. Perhaps because of the length, does a lower rate have to be chosen?
From what I have seen, the remote (compared to the USB Stick) have a more powerful Signal.
But you could anyway try out the ./centronic-stick.py -l
to listen for signals from the remote and see (from different distances) if you miss some.
But as I said, we cannot compare this with the signal of the stick but you may see some possible gaps caused by your configuration
Alternatively, you can try configure each shutter with a different unit.
But keep in mind that a call on channel 15 (broadcast) will no longer work.
Thanks!
I have already tested it with -l. The remote button even work two floors below .They work even when the stick doesn't work.
I will test it again with different units. The broadcast is not required. If that also leads to problems, I buy a new stick and test it with the new one. If that doesn't work either, I use one stick to send the commands and the other one to listen. Maybe that's how I find out.
First of all thank you. I will report again.
Hi,
as the original script is not threadsafe, this may cause the issue (I think that SQLite does not support blocking). The rolling code is not incremented and thus used two (or more) times when the script is started repeatedly in a short time.
I shipped around that by using a lockfile with fcntl.lock as semaphore for the critical part.
Damn good debugging you did. To be honest I was not expecting to have the script running in parallel.
But at the end its a matter of how to manage the shutters.
For instance you can put 1,2,3 into one unit and 4,5 into another unit. If you than run ./centronic-stick.py --send DOWN --channel 0:15
to close all the shutters in unit 0 (so 1,2, 3) followed by ./centronic-stick.py --send DOWN --channel 1:15
to close the other two shutters (4,5) due to a different unit
That could really be the reason!
I will put the files in a separate folder for each roller shutter. Since there is currently a lot of snow on it, it will take a few days before I can test it properly.
Thanks for the tip!
@ole1986: Thanks. I have migrated from FHEM to OpenHAB - and had that issue because I didn't want to add extra things/items just to e.g. open all shutters in the morning.
@danielkarg That will most likely not work - only if you use a different remote (the 'code' in the DB) for each rollershutter as I think that the rollershutter increment their rolling code for 'their' remote even if they are not the target of the command.
P.S.: Here's my diff for the centronics-stick.py file. I didn't do a fork or a pull as I am not that familiar with Python and GitHub
--- centronic-stick.py 2021-02-10 14:58:55.404855594 +0100
+++ ../centronic-stick.py 2021-02-07 11:44:05.460676381 +0100
@@ -6,6 +6,7 @@
import time
import sqlite3
import socket
+import fcntl
import serial # pyserial module required
import time
import re
@@ -16,6 +17,7 @@
ETX = b'\x03'
DEFAULT_DEVICE_NAME = '/dev/serial/by-id/usb-BECKER-ANTRIEBE_GmbH_CDC_RS232_v125_Centronic-if00'
+LOCK_FILE_NAME="/tmp/centronic-stick.lock"
NUMBER_FILE = "centronic-stick.num" # (deprecated) previously used to store increment counter
CODE_PREFIX = "0000000002010B" # some code prefix 0-23 (24 chars) followed by the increment
CODE_SUFFIX = "000000" # some code suffix right after the increment
@@ -397,6 +399,10 @@
showhelp()
return
+ # lock file for concurrency
+ fp = open(LOCK_FILE_NAME, 'w')
+ fcntl.lockf(fp, fcntl.LOCK_EX)
+
with Database() as db:
for (opt, arg) in opts:
@@ -445,6 +451,9 @@
elif mode == Modes.Send:
stick.send(argument, channel, test)
+ # free lockfile
+ fcntl.lockf(fp, fcntl.LOCK_UN)
+
except getopt.GetoptError:
sys.exit(2)
except KeyboardInterrupt:
I might think of putting this into the master branch
Same issue here, I thought that this was a signal issue as well but after some retraining the shutter did work again without any change. Need to remind myself to check this!
Hi,
First of all, thank you very much for providing this script!
I have a problem. I connected the stick to three shutters (channel 1-3). The distance between stick and shutter is between 2 and 6m.
The control does not work temporarily. Even sending the command several times in a row does not result in any movement. It is not always the same roller shutter. If I try it 10-15 minutes later it works.
What could be the problem? Are there any tips?
Thanks a lot!