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.
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:
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.”
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:
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).
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!
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?
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:
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?
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.
Here are some of the automation I have already realized with FHEM and Raspberrymatic, all windows have Homematic sensors:
all Rollos run on automatic mode, since they work slower and more silent than when a command is executed
on weekends or when we leave the windows open at nicht, rollos are set to manual mode, so that they don’t open automatically.
I have the sun sensor connected to some of the rollos. When the internal temperature is too high, and this is measured by Raspberrymatic, I enable the sun mode on Rollotron. Rollo won’t be closed when the sun shines and is cool inside.
when windows are tilted or open, detected by Homematic sensor, rasbperrymatic sends a command to activate the Ventilating Mode.
Except for the Sun sensor, I could do everything else with the Rollos in Manual mode, but they would run on the fast and loud setting.
I do all of that in HA, in manual mode. Slower and less noisy would be great, but it depends on the hardware I think. I use many 1200 which only have one „speed setting“.
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.
