Hey guys, anyone else having issues with 0.89?
Setup of duofern fails since then.
https://github.com/gluap/pyduofern/issues/1
EDIT: Got it working, see referenced GitHub issue.
Hi, I’m new to this thread and I would like to say thank you first for creating this component. I was using FHEM + MQTT as a bridge for a while, but this one is much better.
Yesterday I tried to move to this component and set it up like described here: https://github.com/gluap/pyduofern/tree/master/examples and after fiddling around I got working with hass.io - almost.
Almost because I can not control any roller shutter. Pairing worked well, all roller shutter actors appeared in HA, if I control a roller shutter via remote control I receive the updated position and open/close status in HA as well.
Only controlling via HA does not work. I already enabled debug log for the component and it looks like messages are send:
2019-03-14 14:17:16 DEBUG (SyncWorker_13) [/config/deps/lib/python3.7/site-packages/pyduofern/duofern_stick.py] sending 0D01070300000000000000000000006fdeda42597a00
2019-03-14 14:17:16 DEBUG (SyncWorker_13) [/config/deps/lib/python3.7/site-packages/pyduofern/duofern_stick.py] added 0D01070300000000000000000000006fdeda42597a00 to write queue
2019-03-14 14:17:16 INFO (Thread-3) [/config/deps/lib/python3.7/site-packages/pyduofern/duofern_stick.py] sending 0D01070300000000000000000000006fdeda42597a00 from write queue, 0 msgs left in queue
2019-03-14 14:17:16 DEBUG (Thread-3) [/config/deps/lib/python3.7/site-packages/pyduofern/duofern_stick.py] writing 0D01070300000000000000000000006fdeda42597a00
2019-03-14 14:17:18 DEBUG (Thread-3) [/config/deps/lib/python3.7/site-packages/pyduofern/duofern_stick.py] writing 81000000000000000000000000000000000000000000
But the roller shutters don’t move. Any idea?
Thx.
Never mind I got it working using the same network code I used in the FHEM setup.
@ gluap, Paul
The have changed the directory structure of custom components beginning with HA 0.88.
See blog post: https://developers.home-assistant.io/blog/2019/02/19/the-great-migration.html
Duofern is still working but needs to be modified to work with the new structure.
I have made the modification as suggested in the log and it is working as expected.
Are there any further modifications need to be done?
Could you please help and have a look at the issue?
2019-03-23 20:29:36 WARNING (MainThread) [homeassistant.loader] Integrations need to be in their own folder. Change cover/duofern.py to duofern/cover.py. This will stop working soon.
Hey Tom, when did you setup/update your DuoFern custom component?
It seems your proposed change already exists in his GitHub repository: https://github.com/gluap/pyduofern/tree/master/examples/homeassistant/custom_components/duofern
eXtatic you are right. I have installed it long time ago short after Paul has released the component.
After that I have done one or two updates. Since I haven’t looked in the repository for any updates again because the component was working without issues for me. This warning get my attention after I upgraded home assistant from 84.7 to 90.1. I had to modify some things due to breaking changes in the newer version so everything is working as expected again.
After installing pyduofern-0.25 the cover isn’t detected anymore 
Successfully installed pyduofern-0.25
Error while setting up platform duofern
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform
SLOW_SETUP_MAX_WAIT, loop=hass.loop)
File "/usr/lib/python3.5/asyncio/tasks.py", line 400, in wait_for
return fut.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/haadmin/.homeassistant/custom_components/duofern/cover.py", line 19, in setup_platform
stick = hass.data[DOMAIN]['stick']
KeyError: 'duofern'
I have also replaced my old custom component files with the new files from github:
pyduofern/examples/homeassistant/custom_components/duofern/
What’s wrong? What must I do that the component is working again?
Sorry, got it working. It is always good to read the documentation. 
My configuration of the duofern component was wrong in my configuration.yaml file. The old configuration with “cover” did not work anymore. I have to use “duofern” instead.
…
edit 14/09/2019: can’t answer below my own post, so I have to edit this one.
After switching from homeassistant to hassio and docker I have the same problem again.
I can’t use the friendly name I have set after pairing.
In my .duofern.json
The following devices are configured:
id: 61474b name: schlafzimmer
id: 614730 name: wohnzimmer_klein
id: 61474c name: wohnzimmer_gross
If I use cover.wohnzimmer_klein or cover.wohnzimmer_gross I got
“Entität nicht verfügbar / Entity not available.”
Strange. Why?
But cover.schlafzimmer is working.
If I use the id it is working.
cover.614730 and cover.61474c
Used on card view in lovelace-ui.yaml
...
- type: entities
title: Wohnzimmer
show_header_toggle: true
entities:
- cover.614730
- climate.wt_heizung_wohnzimmer
- cover.61474c
- climate.heizung_wohnzimmer
- type: entities
title: Schlafzimmer
show_header_toggle: true
entities:
- climate.heizung_schlafzimmer
- cover.schlafzimmer
...
Has anyone an idea what is wrong with the config?
I think you can safely update to the new firmware. Here’s a tutorial on how to use it in Home Assistant: Rademacher Homepilot in Home Assistant
Would still be nice to have this supported natively.
So this sounds like a possible solution to integrate RolloTron rollershutter via DuoFern into Home Assistant, right?
I‘m completely new to the Smart Home and especially Home Assistant game but my first priority is to automate rollershutters with tightener systems without needing to use expensive vendor bridges.
I only found one article where someone managed to get it work on FHEM. So I‘m glad to discover this topic here, maybe things are possible!
I tried to figure out what components are actually needed. Can someone please point me in the right direction:
- Rademacher Rollershutter e. g. RolloTron Comfort DuoFern 1800-UW (https://www.amazon.de/dp/B0085IEK7S)
- USB sender on 434,5 MHz (no idea which one is suitable, what range can be expected and if the signal interferes with ZigBee stick next to it) attached to Home Assistant server. The one mentioned in this topic (https://www.amazon.de/Rademacher-USB-Stick-7000-00-93/dp/B00IZAGLSM) seems to not be available any longer
- Most difficult part: software integration part (this topic). Is it possible to do for a newbie (with a bit of technical skills and motivation but without programming skills)?
I try to go through the rest of this topic but maybe someone can give me a kick start on this first smart home project.
Update: I really digged through all the information currently available on this.
It looks like the most convenient way to get @gluap´s great work going when using HASS OS is to use the HACS integration (currently only by setting it as a custom repository, not yet in the official repo).
- First implementation (basis):
pure Python - https://github.com/gluap/pyduofern - Second implementation for HASS OS users:
using custom component - https://github.com/gluap/pyduofern/tree/master/examples - Third implementation for HASS OS users (kinda same like #2):
using custom component - forked and archived https://github.com/dhzl84/pyduofern#setup-custom-component - Latest implementation approach for HASS OS users:
HACS integration https://github.com/gluap/pyduofern-hacs
It would be great to have an update on the current plans by @gluap and all other HASS OS users having implemented it on how it works on a long-term view.
All that information makes me feel quite confident to finally get one of those rarely available DuoFern USB sticks (70000093) now.
@e-raser Incidentally today I updated the HACS integration adding a config flow dialog for setting up the stick (or rather making it visible). I’m a bit hesitant getting it into the official HACS repo, as the prerequisites are not entirely clear to me, especially two steps:
Check Brands: will require me to upload a brand logo to the brands repository – I don’t own neither the name nor the logo of duofern and so don’t think I’m legally permitted to submit these.
Check Wheels: Will require me to add the required packages to a home-assistant “wheels-custom-integrations” repository. While I am not opposed to it, it is unclear to me why it is required.
I guess with enough digging I could answer at least #2 or even both but din’t quickly find them so decided that “add custom repo in HACS” isn’t that big a hurdle for adopters.
Wow, thanks for the view behind the scenes. We users simply are not aware of those many tasks needed to finish for developers. I feel sorry to be not helpful in any way
For the copyright thing (#1): there are a lot of addons/custom integrations especially of the community using brand elements. I use ShellyForHass from HACS which uses the official Shelly logo (as does the official integration), for sure there are many others too. I would hesitate too in such copyright topics but all the other devs seem to have found a way. Shouldn’t there be guiding material for maintainers?
For me adding a custom repo in HACS is no big thing, I have fears of everything needed to be done after that easy thing DuoFern stick is ordered and on the way, hope to continue next weekend and I‘ll go with the HACS way, as obviously the most convenient. As few users proved (in this topic) even on HASS OS it’s possible, I just hope to not spend hours or even days to integrate my first Rademacher roller shutter device.
Big thanks again for porting the FHEM base to Home Assistant, you guys rock! 
@gluap Have a look how the Schellenberg community worked on this (freshly released an addon), maybe you get an inspiration related to brands topic:
HACS integration working great 
- A little bit more assistance on pairing devices and
- a note in the documentation the entity with the device ID will be created
would be great.
Unfortunately I played around with the other services and ran “duofern.clean_config” which removed the systemcode from duofern.json. Deleting the integration and readding it unfortunately does not write the .json with the systemcode. What is the syntax for the duofern.json @gluap?
Currently I have
{
"devices": [
{
"id": "ABCDEF",
"name": "ABCDEF"
}
]
}
and I´m sure that will break future pairing attempts.
Update: Fixed it by starting from scratch (removing integration, removing HACS integration, HA restart, adding HACS integration, adding integration, repairing device). Without this full process the duofern.json has not been created/updated with the system code. Should finally look like this:
{
"devices": [
{
"id": "ABCDEF",
"name": "ABCDEF"
}
],
"system_code": "XXXX"
}
homeassistant.log is pretty flooded with the HACS integration messages, but at least it works. Thanks soooooooooooooo much @gluap !!! 
1 Like
Hi @e-raser, actually when switching to hacs I meant to only keep the duofern.json as a mechanism for people migrating from an older version. That it is apparently still written (and read) could be considered a bug. Ideally everything would be stored in homeassistant when using hacs. I’ll file it as a bug for myself to fix.
I’m sorry for the pairing process being somewhat unintuitive. I agree, and originally the “call a service” hack was mostly a workaround. When I was looking into how to do allow a pairing dialoguet via a config flow it seemed impossible to do (at least to me) with the frameworks provided by homeassistant at the time. I think the whole config flow framework has matured since then, so maybe the best way would be to just give it another go.
Oh now that I know how to pair it´s “simple enough” for me, I´m getting used to it.
Good to know the duofern.json is some kind of legacy. I also discovered it “never” gets updated (e. g. when changing names of devices). So I had a look around and - voila - everything seems to be stored in the HA default place /config/.storage/core.config_entries including the system code.
So maybe the .json can be removed in a future update?
Hey guys, I recently came around this awesome port and found the radio-stick online. I set everything up and it mostly works fine in HA, but I have problems with my HomeKit integration.
Sometimes I am not able to control my shutters via HA and HomeKit and I have to restart the server. Most times everything is controllable in HA but no changes are synced via HomeKit to the Home.app on iDevices and I’m not able to control the shutters from there.
I’m not sure where the error lies, but everything else I have works well with HomeKit.
Maybe someone on here can help me figure out whats wrong?
Hi Paul
I’ve just finished the migrating of Duofern Rollos from FHEM to HA, and so far position and control are working nice.
But I’m missing the other commands such as manual and auto mode, Sun automatic and mode, and ventilating mode. Is there any plan to implement these statuses and commands as well?
I think the author of this great piece of software will answer this soon.
But… for what would you need the different modes? With HA you basically use the devices in manual mode and create the kind of auto/sun/etc. stuff with automations. I never missed any of the manufacturers default modes.