These are the status updates that are failing to make it through to home assistant:
2020-05-27 22:45:11 DEBUG (MainThread) [watcher] [rakomqtt.RakoBridge] received byte_list: [83, 10, 0, 9, 0, 50, 128, 0, 0, 1, 0, 68],
2020-05-27 22:45:11 DEBUG (MainThread) [watcher] [rakomqtt.RakoBridge] unhandled bytestring: 50 is not a valid RakoCommandType,
2020-05-27 22:45:12 DEBUG (MainThread) [watcher] [rakomqtt.RakoBridge] received byte_list: [83, 5, 0, 9, 0, 15, 232],
2020-05-27 22:45:12 DEBUG (MainThread) [watcher] [rakomqtt.RakoBridge] unhandled bytestring: 15 is not a valid RakoCommandType,
The first one (50) is a FADE command. I’m not exactly sure how to decipher if it was a fade up or a fade down (ie you pressed the button on the wall plate)
The second one (15) is a STOP_FADING command (ie you released the button on the wall plate).
Neither of them show data about how what brightness level you were fading from or to.
Out of interest, which wall plates do you have? We only have the RCM-070s and we never ever use the fade buttons, only the scene buttons, so i never bothered trying to implement fade status updates!
ill see if i can recreate locally and have a think about possible work arounds to support fading…
I also have the RCM-070 wall plates, I believe developers configure the 4 buttons like scenes. So to give an example the logs are from my living room where I have a ceiling light and also spots both on a separate channel; (Room 9, Ch1:Ceiling Lights, Ch2:Spots).
Than on the wall plate scenes are configured like this;
I did not use fading buttons, but I guess you are right about the fading because I used the preconfigured wall plate buttons and they are programmed to fade to certain percentage depending on which scene is selected.
Hi, I had the same error message when I tried to load the container using Portainer. I believe it relates to the architecture of the container? I am trying to run on raspberry pi 4 which is arm and this was amd64.
Once I downloaded and created the container manually it worked. Although docker-compose wasn’t present so I couldn’t use that. Instead using ‘docker build .’
There is some two way interaction between the rako switch and home assistant, but I think this is at room level rather than channel?
thanks for the tip on the chip architecture, youre probably right, im not building the image on arm and am running supervised HA on ubuntu. i opened this to address it…
I can see what youre asking for here, but im not sure how it’s possible because the rako bridge only issues status updates at the level you send the command. allow me to elaborate…
example 1:
i. set scene 1 for room 42. this can be done in the rako app/wall plate/HA via mqtt command_topic: “rako/room/42/set”
ii. rako bridge sends a state update of “scene 1 was applied to room 42”, which gets sent back to mqtt state_topic “rako/room/42”
NOTE: Rako room scenes 1,2,3,4,off are mapped to home assistant brightness levels 255,192,128,64,0 respectively (1 being the brightest, 4 being the dimmest).
example 2:
i. set level 255 (100%) for room 42, channel 5. this can be done in the rako app/HA via mqtt command_topic: “rako/room/42/channel/5/set”
ii. rako bridge sends a state update of “level 255 was applied to room 42, channel 5”, which gets sent back to mqtt state_topic “rako/room/42/channel/5”
the feature i perceive that you’d like is all the functionality of example 2, but a small modification to example 1:
i. set scene 1 for room 42. this can be done in the rako app/wall plate/HA via mqtt command_topic: “rako/room/42/set”
ii. rako bridge sends a state update of “scene 1 was applied to room 42”, which gets sent back to mqtt state_topic “rako/room/42”
additionally, all channels that are affected by the scene change are sent back to mqtt state_topic “rako/room/42/channel/*” with their individual brightnesses
there must be a way to do this, because the rako app updates channel levels based on wall plate key presses, but i’m not sure exactly how!?
Hi, I’ve been thinking about this some more. I’m wondering if I should change the channel of the remotes so they trigger an event that homeassistant picks up. Home assistant would then send the signal to the lights on the right channel. That way hone assistant would stay in sync.
@marengaz Thank you for doing this, I have spent 6 weeks trying to get Rako Lighting working with HA while learning a lot about HA and hass.io.
I have tried your marengaz rakomqtt method, setting up one light initially to see if it works and I get no response. Is there a way to test where it is falling down? I moved HA from a Rapberry Pi to a NUC because I read in your GItHub that it was not RPI compatible.
As an alternative I have also tried to connect using the Homekit controller with Rako Cloud Gateway (No success here yet either) Has anybody else got that working?
@marengaz I hope you don’t mind, I wrote a newbies guide to implementing you method and put it here
I would love to know if you have found a way of getting the status of the lights back into home assistant.
Apple Homekit seems to manage to get status of lights correctly even if the lights are changed using buttons or Alexa and I would love to get that functionality with Home Assistant. It does have to use the Rako Cloud Gateway rather than the Rako RTC Bridge though.
Reads well. But in the nicest possible way, hopefully it will soon be redundant…
I spent a lot of time over Xmas break cobbling together a proper Hass core - rako bridge integration (local push) with Config flow and discovery and all that good stuff. Didn’t quite manage to get a pr out yet, but hopefully in Jan some time depending on how busy I am at work. Think I’ve done about 85% of the coding work though.
The finished product should include all the feedback you guys have all given here and we can abandon the rakomqtt container
That is amazing news, thank you for all your hard work. If you need any help with testing I’m very happy to volunteer. What does config flow ad discovery mean? Any way of getting access to the Rako switches states and the ability to use them as entities?
‘discovery’ means hass can auto detect what lights are attached to your bridge and auto add them as entities.
the combination of both means no yaml
rako state in home assistant:
i haven’t coded this bit yet, but the rako bridge wasnt really designed very well.
it holds a cache of what state it ‘thinks’ the lights are, rather than checking with the light controller for the actual state. the best i can do is check the bridge’s cache.
i think the cache stores either room scene (1,2,3,4 on the wall plate) or channel level (fade up or down) rather than both.
not totally sure how to make this work yet, but i should be able to make the same estimations that the rako app does, because it uses the same protocol as im using.
Hi just new to the HA party and have a house full of Rako gear with a Rako bridge (ie not the new Rako hub or the Rako cloud gateway).
Struggling a bit to get the existing integration to work - I can get the container running in Portainer but then what. I had expected to enter the IP address of my Rako bridge somewhere but that doesn’t seem to be in the steps unless I missed it.
What Rako bridge device are you using? Just the regular one or the one that integrates with Alexa etc?
Great to see you’re working on native/core Rako integration. I’d be very happy to get involved in testing that if it helps.
I had the same interpretation as you from the Rako integration docs about how feedback works - does seem a bit shortsighted of them but I guess it is 15+ year old design.
Hi Peter. Thanks for coming back so quick. I had seen that but couldn’t figure out why nothing was happening. Figured it out tonight though. There were a couple of issues - a rogue “Schema” instead of “schema” in the yaml file and an issue with Mosquitto user setup. All working now.
I noticed yesterday that when the playroom lights were turned on at the switch the status of the light in HA correctly changed which doesn’t happen with my other lights. I realised this is because the playroom Rako switch directly turns the light in and off as opposed to triggering a scene in in Rako. Most other rooms, the switch activates a scene, even if the scene is ‘set the light at 100%’.
I’m tempted to reprogram Rako so the first button in each room (what most people use) is a simple switch so that HA gets the right state.
The aim of this pr is to get feature parity with the rako app, so if you notice anything that the app can do that this home assistant integration can’t, let me know!
If you have some time and wanna test it out and give feedback before it’s merged, please:
unzip and grab the directory at homeassistant/components/rako
put that directory on your home assistant server at <config_dir>/custom_components/rako (i use the VS code addon)
Reboot home assistant
put rako: in your configuration.yaml
Reboot home assistant
go to configuration > integrations > add > rako and everything should auto discover
If you’re already running rakomqtt, then you’ll have to stop that pod, otherwise there will be a port clash. Your mqtt broker can obvs stay running though
Debug logging can be enabled by amending your configuration.yaml to look like this (reboot after adding it):
logger:
default: info
logs:
homeassistant.components.rako: debug
python_rako: debug
in the configuration > logs page you will have to click ‘Load Full Home Assistant Log’ and search for ‘rako’.
As you know I have been using your old method. Should i remove all the lights from the configuration.yaml file first?
these will not continue to work without the rakomqtt pod, but they will also not conflict, so you can leave them there if you want.
I assume the entity names will remain as before so all the automations and node red flows should carry on working?
your current entity names are arbitrarily defined by you in the config yaml. the entity ids for this new integration are autogenerated based on whatever they are named on the rako bridge.