That’s interesting. I wondered how deconz does the linking, but never bothered to check.
Already have an initial version of it working, also gonna expose roku_usn as a configuration option.
If you want a reference implementation I recommend looking at the zone component
Yeah, that’s what I looked at first.
Though as I understand config entries are not quite finished yet. Should the domain config from configuration.yaml be imported?
If it is, then config changes won’t work, the config entry has to be modified. If it is not imported, the config won’t appear on the UI. Is updating a config entry when the configuration.yaml changes supported? I couldn’t find any docs. The zone component doesn’t import config entries from the yaml.
Also I’m thinking of creating a default emulated roku entry (On the default roku port 8060) if the user doesn’t specify any configuration in configuration.yaml, just the domain, which would appear in the UI.
Would this be too much automation for a component, am I trying to oversimplify it?
The short answer; you can support either or both ;). For zones Balloob just wanted them to be separate to keep the old behaviour when upgrading and having a different flow when using config entries. For deconz Im gonna move away as much as possible from configuration.yaml, but I need to wait a few releases to make sure that all have upgraded before removing the legacy configuration.
Updating a config entry when a configuration in yaml has changed is possible, but I personally think that gets overly complicated to support. Why not just do configuration entry now that you’re creating a new component?
What I would do is to only support it through config entries.
Simplification is nice, but it is good to allow additional options as well. I would have default values for all parameters and just allow people to override those if wanted. So more or less you would only have 1 page, where all parameters are visible with the descriptive texts describing the default values. Which would all be the same behaviour as you explained for configuration.yaml but in config entries instead.
So is UI config (and the json) the way forward? No yaml?
Unfortunately I can’t get default parameters in the UI to work at all, so I just have fallbacks in code if the entry is an empty string.
The only required parameters now are the name (the roku usn, but using the ‘name’ config is simpler) and listen_port.
What I meant that I would create a config entry by default. Though on a second thought, it’s so simple to create a new config entry via the UI, creating one automatically would just cause problems.
I have the branch up on gitlab:
Just a quick report to say I’m still loving this, thank you @mindigmarton. I recently had my SD card fail and had forgotten to do a snapshot for a while 
so took the opportunity to rethink some things.
Because you can have multiple instances of it, I set one up with Lights as the device name and just used that for lights controlled by HA, so now under the devices menu on my remote I have a dedicated Lights section similar what you get if you use the home control function. You obviously don’t get the status showing but it’s simple enough to rely on my eyesight to tell me when controlling them manually 
. Other functions which are just used as triggers within activities are hidden away under other ER devices.
Yeah, that is not supported yet. You can just do a .get(‘value’, default_value) to create your config. Would be the simplest work around
I kinda want to support both until config entries is more mature. I cannot get typed fields to work either. Anything that is not str becomes a required field…
Also, I figure it would be best if I kept the yaml and config entry completely separate.
Hmm. The Zone component has both kinds and it works as expected
Regardless, if you want to support both ways thats great! It is your component after all
Yeah, the Zone component doesn’t work either. Radius is optional, but an empty string is passed to voluptuous from the UI, and that cannot be coerced into a float. Tested with Chrome and Edge. Should error messages appear in the UI?
If not, I’m not gonna spend more time with it and just to string fields for now, and do proper types when the config framework is ready.
You should get error messages in the gui.
Radius works for me with safari and the testing passes as well. Will double check that.
No error messages at all. For now I’ve added additional server side validation that the passed in string isn’t empty with an additional voluptuous schema in the flow…
(don’t quite like it, but the UI is not functional otherwise: https://github.com/mindigmarton/home-assistant/blob/emulated_roku/homeassistant/components/emulated_roku/config_flow.py)
Almost everything is ready to go, just need to write a few tests.
A small comment to simplify, you don’t need the try except
with all ‘optional’ values add a default value in you get and remove 70% of your lines of code in validate user input method
e.g. user_input.get(CONF_NAME, DEFAULT_NAME)
So, the issue is that all the optional values (and even required!) are empty strings.
So .get default values don’t work. I have to check for falsiness, convert the value to the correct type, then check that input against the actual schema, which will throw errors if for example, name is missing because the UI validation for required fields don’t work.
I tried with the latest Edge, Chrome, Firefox doesn’t even load the UI (hasn’t worked for a year now)
Maybe I should wait till it’s fixed?
Well, a lot of people are using Firefox so I think that would have been reported if that was the issue.
I will check tomorrow evening if I only get strings or ints as well.
Aand I’ve just read the new comments since I’ve last checked. LastPass plugin causes it, huh.
So I’ve checked out the polymer code and it looks like server errors are not caught.
(is there client side validation for required fields? I can’t find anything in ha-form)
Looks like it’s already reported: https://github.com/home-assistant/home-assistant-polymer/issues/1140
How do you control the dimmer? I’ve been trying to think about how to dim using the Emulated roku, but have not been able to figure it out
As I said, the dinner is standalone, nothing to do with HA.
I do ‘dim’ my Yeelights with it though, I’ve made scenes at a few set brightnesses and assigned then to Roku buttons. These are then set to the up down buttons on the remote so for users it feels like they’re using a dimmer.
1 Like
Unfortunately not, it’s pretty much completed, but it’s been sitting on my branch because of the issue mentioned above, and it took way too much time to work around it, and I don’t like the solution (and didn’t want to exclude fields from the config UI)
Looks like the fix is in progress: https://github.com/home-assistant/home-assistant-polymer/pull/1662