I finally found the reason for my issues by misstake, I were troubleshooting another component (ICMP ping) and went deeper into permissions and PATH issues, it seems like I’ve added a line to my systemd service which disabled the use of my original OS path’s
It was the rows with ‘#’ before them, except the first row of course since thats an actual comment.
I hope this might help someone else who’s making stupid misstakes
[Service]
Type=simple
User=homeassistant
# Make sure the virtualenv Python binary is used
# Environment=VIRTUAL_ENV="/srv/homeassistant"
#Environment=PATH="$VIRTUAL_ENV/bin:$PATH"
ExecStart=/srv/homeassistant/bin/hass -c "/home/homeassistant/.homeassistant"
[Install]
WantedBy=multi-user.target
From the looks of it, the motion sensor communicates directly with the bulbs without going through the gateway so it’s currently not possible to do what you look for.
I thought I answered in this thread as well, but it seems i didn’t: At this point (who knows what’ll happen when Ikea releases their update) it is not possible to capture motion state from the PIR sensor. it triggers the light directly.
Recently, my gateway starts to stop responding to pings (which I check via HASS) and is therefore also unavailable for HASS. I then need to power it off and on to make it work and respond again. Does someone encounter similar issues?
Before it worked weeks without this issue, know I need to power it off once or twice a week.
I also have not been able to find any source. But its really annoying if the gateway stops working. I am already considering to power it on/off via a controllable power socket in order to prevent it from being unresponsive.
A contributor to OpenHAB has figured out that Tradfri will allow you to have “empty” groups that contain only a switch but no lights - and that the state of the group (off/on) is still updated when the button is pressed, even though there are no lights. (See: https://community.openhab.org/t/ikea-tradfri-gateway/26135/75 and see also pull request to that project here: https://github.com/eclipse/smarthome/pull/3799). Thus, other components can be controlled with the Tradfri switch.
I’ve fiddled around with my Tradfri in HA with the “allow_tradfri_groups” config directive but the status of the group reported in HA doesn’t seem to be updated on button presses - I need to test this more to be sure if it’s HA or something about the way I’ve set Tradfri up.
There’s no mention of motion sensor in the above links but maybe it works the same way? I.e. An empty group is still turned “on” by motion?
I have retested and can confirm: Tradfri switch in a group by itself in the Tradfri app will toggle the group’s state on and off in HA when the group is passed to HA with the “allow_tradfri_groups: True” directive in the config.
The same does not appear to be true for the motion sensor, sadly.
@marthocoo I just tried this but it seems VERY slow on updating the status from off->on / on->off and that means its unusable, is that also your experience ?
Yes it is currently slow (5-10 seconds) and unreliable (a button press may or may not change the HA state either off or on). So not usable to trigger automations at the moment, but I put this down to the implementation in HA, which should improve.
The interesting part though is that, at least when the switch is in a group by itself, it does communicate with the bridge, which previously was not thought to be the case.
So i’d like to know from users that have the IKEA Remote (5 button) if they see that occasionally the lights does not react to the button push like it’s misses the button push ? I see the remote using my own implementation together with RaspBee gateway occasional misses a button press and i’d like to know if anybody also experience that with the IKEA HUB/Gateway
and again, yes, I expected the same. But I saw the same thing as you. It stayed as before. It might bee that the remote control is lazy in the effort to initiate retransmits (or even did not send them at all) when it comes to transmission errors. The base/gateway seems to try for 10 seconds to retransmit commands. When the 10 second threshold will be exceeded the availability flag in the bulb data will be set to not available for the related bulb. My observations let me suppose that the remote control acts more reliable when i peer them directly to the light bulb. When connecting them to the base/gateway station the “no reaction” behaviour can be seen more often.
I think yes, there is no other way. You start to peer the remote control with the base/gateway/hup and then you go with the prepared remote control to the light and peer that with the remote control. There is no other way to peer a light with the hub and when you disconnect (throw the peering by pressing the button four times) the remote control and after that you peer again the bulb with the remote control, the connection to the base/hup will be lost and will be replaced with the direct relation of the bulb to the remote control. As I understand the mash behaviour of the zigbee-network this is only a very little difference doe to the fact that the bulb will be able to act as a relay and can resend the message from the remote control to the base station when the given topology will prevent the base from “hearing” the remote control directly. But in practice it behaves differently… But at all I feel happy (enough) with the tradfi system, the light of the bulbs is very good and my application is to switch the color of the light and the degree of dimming by a server application for that I build a python based server that can be controlled by a cron job. If the bulb did not react doe to the fact that it would be switched of by the regular wall switch, I manage the retransmission after reappearing of the light. This works reliable most of the time but I am still evaluating that.
