For anyone else confused, I found the commands usable in the HA code here…
Namely…
Home
Rev
Fwd
Play
Select
Left
Right
Down
Up
Back
InstantReplay
Info
Backspace
Search
Enter
All working like a charm now 
1 Like
Pushed a new version with some fixes for discovery (android remotes work now) and made some changes to the device info and apps template.
There are 10 dummy apps (app_id 1-10) which can be used in HASS. (‘launch’ type)
Unfortunately Harmony roku apps do not work over wifi (I guess it’ IR?)
Also formatted the code according to HASS style guidelines.
No change in configuration / usage.
Next up: creating a sensor for buttons instead of events.
1 Like
Do you have any plan for bringing this upstream?
Momentary events like button presses are expected to be represented as events in hass.
Really? I thought I saw things with buttons as sensors in HASS. If not, I’ll leave it as is.
Some Roku remotes send key down / up instead of keypress and that only makes sense as ‘key is down’ state which I’m not sure how I could represent. Rather not spam events, but long press detection could be useful I guess. In either case the primary usage is Harmony and it only uses ‘keypress’.
Yeah, I’m preparing to open a PR sometime, that’s why I formatted the code 
1 Like
Great! Looking forward to using this once it is integrated.
I have a PR for a zigbee component, discussions with Balloob went like that. The Remotes send multiple events, like short press and then long press and later release of button. Since the events are only relevant during that moment there is no reason to expose it as a sensor. I did that initially but after some discussions I changed to doing events instead.
Might have missed the point but the receiver has no idea which of those it is, they’re an internal thing to Harmony. This component doesn’t interact with Harmony in any way like the Harmony component, it just pretends to be a Roku device which you could control with anything that could send the relevant code, eg a genuine Roku remote.
Why wait to try it if you think you’ll make use of it?
That example was from my implementation, not a 1 to 1 mapping with the Roku thing.
Im completing my own PR, and then when that is done I need to migrate my hardware.
After that I have a couple of issues that needs to be resolved on another component.
So lets just say its a limit on my automation time
1 Like
Which ip address shoud i insert ? I get an error Unable to find component emulated_roku
I have added it with the IP address of my HASS installation and can find the emulated ROKU in my Harmony app.
emulated_roku:
host_ip: 192.168.**.***
upnp_bind_multicast: True
listen_ports: 8060
Oke. So I have added the emulated roku information to configuration.yaml and have added the ROKU device to my Harmony app, so far so good.
I am pressing some buttons in the Harmony app and some logging is appearing in HASS(.io).
2017-12-08 19:19:15 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 1897912816: Sending {'id': 820, 'type': 'event', 'event': {'event_type': 'roku_command', 'data': {'roku_usn': 'bFiyKZgUDw7LxhmeDkz2cZ', 'type': 'keypress', 'key': 'Fwd'}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2017, 12, 8, 18, 19, 15, 505842, tzinfo=<UTC>)}}
2017-12-08 19:19:15 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 1897912816: Sending {'id': 820, 'type': 'event', 'event': {'event_type': 'roku_command', 'data': {'roku_usn': 'bFiyKZgUDw7LxhmeDkz2cZ', 'type': 'keypress', 'key': 'Fwd'}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2017, 12, 8, 18, 19, 15, 856710, tzinfo=<UTC>)}}
2017-12-08 19:19:16 DEBUG (MainThread) [homeassistant.components.websocket_api] WS 1897912816: Sending {'id': 820, 'type': 'event', 'event': {'event_type': 'roku_command', 'data': {'roku_usn': 'bFiyKZgUDw7LxhmeDkz2cZ', 'type': 'keypress', 'key': 'Fwd'}, 'origin': 'LOCAL', 'time_fired': datetime.datetime(2017, 12, 8, 18, 19, 16, 44738, tzinfo=<UTC>)}}
But in HASS the ROKU device is not discovered (should this be the case?). Manually adding it to confguration.yaml is also not working.
But how can I trigger an automation based on the above events? The below automation is not working 
- id: roku_test
alias: Roku Test
trigger:
- platform: event
event_type: roku_command
event_data:
roku_usn: bFiyKZgUDw7LxhmeDkz2cz
type: keypress
key: Fwd
action:
- service: notify.telegram
data:
message: 'Roku TEST!'
Can someone help me with this issue? (btw. manually triggering the automation is working)
Thanks in advance.
This would appear to be a simple second pair of eyes problem
From your log…
roku_usn': 'bFiyKZgUDw7LxhmeDkz2cZ'
From your config…
roku_usn: bFiyKZgUDw7LxhmeDkz2cz
Hero! Thank you very much!
You’re welcome 
I’ve had some issues getting this component to work. I see the emulated device get picked up by my harmony but the component will not register fully with HASS. I believe it to be related to running python 3.4.2 and it’s async lib. Has anyone had luck getting this component to work with that version of python? Been meaning to upgrade anyway but wanted to confirm my suspicion.
Here’s a relevant log snippet when starting hass:
Traceback (most recent call last):
File "/usr/lib/python3.4/asyncio/tasks.py", line 237, in _step
result = next(coro)
File "/home/homeassistant/.homeassistant/custom_components/emulated_roku.py", line 125, in start_emulated_roku
bind_multicast)
File "/srv/homeassistant/lib/python3.4/site-packages/emulated_roku/__init__.py", line 353, in make_roku_api
reuse_address=True)
TypeError: create_datagram_endpoint() got an unexpected keyword argument 'reuse_address'The code was updated not long ago to make use of a python 3.6 feature since HASS requires it now.
The earlier versions (before 0.1.0) which worked with python 3.4 had socket binding errors on a few linux systems which the missing feature fixed.
So yeah, it’d be easier to upgrade.
noted. Thanks for confirming! Might want to update the readme to declare that python 3.6+ is required since HASS hasn’t fully enforced updating yet.
Hass doesn’t require 3.6. It will at most require 3.5.2 somewhere in the first half of next year. Components using 3.6 only features can not be integrated because of this
Huh, I might’ve misread it then. It looks like 3.5.2 has reuse_address too.
Will test it soon and add the req to the readme.
The code passes lint and the docs are almost ready, but the pr will have to wait till 3.5.2 then…
1 Like
By that logic, you’d just update to 3.6 regardless and not have any problems going forward would you not?
Hass follows debians default python version. And since the aim is for this to be integrated into hass it needs to follow the same rules.