Should host_ip be set to the hass servers ip?
Essentially, yes.
By default it binds to 0.0.0.0 and it advertises that, which won’t work from outside.
Alternatively, you can set advertise_ip if you need host_ip to bind to all or another interface (like docker)
Ahh…I don’t have the component enabled and I killed discovery five minutes after first using HA as all I got out of it was loads of ongoing errors in the log from devices I had no interest in.
Is there any advantage to enabling the component if you don’t have a real one and want to control it.
Would you happen to have a list of the key names that work as the names Harmony uses don’t work eg in your example you use Fwd which works perfectly but FastForward as Harmony itself calls it doesn’t. This is the full list of Harmony names…
PowerOn
DirectionDown
DirectionLeft
DirectionRight
DirectionUp
Select
Play
Rewind
Pause
FastForward
Back
Search
Sleep
Info
PageDown
PageUp
Exit
Netflix
Pandora
Amazon
Crackle
HBONow
Home
Hulu
InstantReplay
MGO
Options*
Showtime
SlingTv
VuduThe library just forwards what it receives as a parameter, doesn’t do any filtering, etc.
Though Hulu and others are not key presses so those won’t work.
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.