Get the Current configured channel

[nicolasberthel]

Thank you for your work! using your code I was able to configure my becker shutters in home assistant. Do you know if there is a way to get from the contronic stick the current channel configuration ?

Thanks
Nicolas

[w0vka]

Thank you for your work! using your code I was able to configure my becker shutters in home assistant. Do you know if there is a way to get from the contronic stick the current channel configuration ?

Thanks
Nicolas

Hi Nicolas,
may i ask how you integrate it in home assistant?
with the "Command Line Cover" or with the Python_scripts" integration?

Thx

[nicolasberthel]

Thank you for your work! using your code I was able to configure my becker shutters in home assistant. Do you know if there is a way to get from the contronic stick the current channel configuration ?
Thanks
Nicolas

Hi Nicolas,
may i ask how you integrate it in home assistant?
with the "Command Line Cover" or with the Python_scripts" integration?

Thx

I create a custom cover component : https://github.com/nicolasberthel/hass-becker-component I'm not a python expert and it's an first version but for me it's working

[ole1986]

./centronic-stick.py -s will output the database incl. a flag which units are configured

While ./centronic-stick.py --channel X will always refer to the first unit in the list you may pick other (configured) units using --channel [unit:]<channel> E.g. --channel 2:1 for unit 2 in the list on channel 1

[ole1986]

BTW: I do have a side project to implement Becker Shutter into Google smarthome.

Its called ga-virtualdevice (Google Assistant Virtual Devices).
https://github.com/ole1986/ga-virtualdevice-proxy

But its more than only Becker shutter - It should give us the flexibility to include any device/module (virtual/or not) into Google Smarthome

It is currently in closed alpha but the goal is that anyone can participate to add additional modules (I called it "Interfaces" atm)

You can find already the following Interfaces:
https://github.com/ole1986/ga-virtualdevice-proxy#supported-interfaces

[nicolasberthel]

Thanks @ole1986 ./centronic-stick.py -rely on the database if I understood, no chance to get info from the stick ?

[ole1986]

@nicolasberthel could you please tell us for what reason you need it?

Since the usb stick can decide by itself what unit to use for which channel I needed to store somewhere.

Also, stick and receiver is a non-bidirectional connect it should not be much relevant on what unit or channel to use

[nicolasberthel]

From my experiences the pairing is stored in the stick I reinstalled several time my Raspberry PI starting from scratch each time :D The command where always working (even with a dummy database). The idea would we to get the channelrs that are already setup and paired

[ole1986]

This would mean the stick also stores the incremental number...
I cannot actually believe this, since the complete code is fully generated by the script (incl. incremental)

[ole1986]

@nicolasberthel

Assuming you reinstalled the raspberry pi, all the data (incl. the centronic-stick.py script and its db - previously *.num file) is deleted.

I would be really much interested in what you did after a fresh raspberry pi system.
Like, what steps you did until using centronic-stick.py again.

What I could imaging that you again paired the shutter against the script. So it may accept the increment of 0 (zero) again.

Also related: https://github.com/ole1986/centronic-py/blob/master/TECHNICAL.md

[nicolasberthel]

What I can garantee is that I never repaired my stick and it worked on several rpi
in the past (without DB I even think that the num file was recreated and it worked fine) for the db version I simply drop an dummy num file (with just a 1 inside) and it work

[ole1986]

That would be pretty unusual when no incremental counter is taken into account and shutters still working.

According to my last experiences with the shutter, the next possible increment can be raised up to a max of 49 and lower numbers will not be accepted from receivers.

Can we test something together and proof that the increment is not used in your case?

Lets assume you have the latest version (v0.6) with the centronic-stick.db file.

Can you please do the following steps?

• run the command ./centronic-stick.py -s and note down the current increment for the unit "1737b"
• than run command ./centronic-stick.py --mod "1737b:<current_increment-2>:1". So if your current increment is 100 for example, please enter 98
• followed by the command ./centronic-stick.py --send DOWN --channel 1 and check if its working?

Please let me know the result
Thank you in advanced

[nicolasberthel]

OK when doing -s

code increment configured last run
1737b 56 1 2020-04-05 21:44

Then I ran python3 centronic-stick.py --mod "1737b:54:1"

And you are right the up command after is not working. (After a second try it worked)

Then I made another try

Again -s gave
code increment configured last run
1737b 56 1 2020-04-08 20:35

I removed the db file and created a num file with 40 (randomly)

Again after 2 try of UP command on channel 1 it worked.

I tried several combiantion with several numbers, by calling -mod or creating num file on different channel and the UP Command then work either directly or after 1 or 2 extra calls

I do not know if it help :)

[ole1986]

To my surprise I can confirm it

More I have figured out:

• turning the shutter off and on again does not reset the incremental counter (so it keeps remembering the last used number)
• The statement about the valid range of max +49 (mentioned in TECHNICAL.md) is still valid
• A command spoof of ./centronic-stick.py --send HALT --channel X for 3 times is enough to force accept the increment by the shutter submitted by the script (no matter what the number is)

A possible attack is becoming much easier

An attacker with this USB Stick attached can overwrite the MASTER SENDER and gain full control on the shutter by only knowing the correct "unit".

The unit is between 0 and 1048575 (0xFFFFF) which sounds much.

UPDATED

Sniff the correct unit

Assuming the victim has configured the shutter to regular open/close on daily bases the attacker could already break into it "during the day" by sniffing the signal using ./centronic-stick.py -l