The hub doesnt have any flashing LEDs on it. They stay constantly on.
I meant that isn't the hub still doing work though, by virtue of being powered on?
1 Like
No, I don’t think that matters. But the users actions should not intentionally cause the hub to do more work.
This Wikipedia article sort of goes into the details …
2 Likes
As you can well imagine, it's a very complicated subject.
-
A very clever response (@hasty1), to disable the device by means of the UI. This is very similar to the response of turning off the appropriate radio. These mean that the Hub will not process the response from the motion sensor, but they don't stop the motion sensor from issuing it's report. Equivalent to these two approaches is just using a switch so that any report from the motion sensor is disregarded in the rules.
-
@rob9 approach is the best, but requires (in this case), a tremendous amount of work that I'm not sure the client is willing to pay for. There are many, many, many sensors to be retrofitted to work on power. Can be done, but it's a big job.
-
Turning off the Hub via a wifi plug (after a graceful shutdown, of course), would seem to be the best approach. However, this means that timed events during the period (e.g. turning the Thermostat up or down, which are permitted), are also not performed.
My thanks to everyone for giving the matter some thought. Much appreciated.
2 Likes
It sounds like the issue could be the physical sensor itself detecting motion, or perhaps a light on the sensor flashing, or the zigbee radio sending a motion event (or all of the above?).
As others have mentioned, I think the only way to stop the sensor itself from doing those things is to remove power.
Everything else is, I believe, at the hub level, i.e. whether the hub does anything with the data the sensor has sent to it.
1 Like
Maybe use a second hub to put all of the devices that need to be disabled on this hub with appropriate rules to shutdown this one hub for the appropriate time. I would assume this would be less expensive than option 2. And give you the flexibility missing from option 3.
2 Likes
This would definitely be an issue. Similar to the light in a fridge coming on when the door is opened.
Could the device be covered in some way? As I was reading this thread, I thought of what @rob9 did... a powered outlet. But I'm thinking a non-electronic method would be a manual drop down cover made on a 3d printer - sort of a box on a rail that can be slid open closed like the privacy window of a camera...
1 Like
I emailed my Orthodox friend yesterday after reading your post, and he sent me this link. It turns out that this is quite a common problem. And while it is desirable to disable the motion sensor, it is not essential to do so. (off course, motion based automations should DEFINITELY be disabled).
https://ph.yhb.org.il/en/01-17-14/
You may wish to share this with your client.
3 Likes
Hue sensors are magnetic, now and again when I don't want anything to run a just grab the sensors and place it somewhere facing the wall so it can't detect motion
1 Like
Thank you!
1 Like
So.
Another thought that might be easier.
Buy a second hub.
Pair the motion sensors and other things that need to be disabled to the second hub.
Mesh it with the primary hub.
Have the primary hub tell that second hub to do a graceful shutdown prior to when motion alerts need to stop. Then, after a bit, set up a rule to kill power using a single outlet.
Then, when things can resume, power that hub back on.
3 Likes
if you're just looking to cut power to a device, are you able to use a relay? you can use this to break the power during the times you want it off and turn it back on when done (with a rule). not sure if that's just causing a new device to be counted as doing work and moving the issue from the sensor to the relay
My guess, not being of that religion, is that you would do that "work" outside is the protected hours, so it didn't matter.
Turn off the relay before the time of concern and leave it off until things are good to go
1 Like
This is interesting. There seem to be many different interpretations, in the detail, of the Shabbat restrictions on electricity, in particular in relation to automation.
From the initial post, given "the motion sensor is not to report motion between those two times", it would seem that the client believes that either the actual detection of movement by the motion detector and of the opening of a window/door by the sensor, or the act of these devices reporting that detection are prohibited during Shabbat.
This seems a very conservative interpretation indeed from what I have read, but the ultimate arbiter of what is acceptable will be the OP's client based on what they believe.
There seem to be a number of elements to the issue that it may be worth the OP exploring with the client, specifically centering around what it is that they wish to prevent during Shabbat:
- any electrical activity whatsoever - in which case the whole system would need to be shut down and battery powered sensors would need to have their batteries removed
- changing the state of an electrical circuit - in which case again as above
- changing the state of an electrical circuit as the result of an action by those observing Shabbat - in which case only the sensors would need to be depowered
- writing to logs - in which case the sensors would need to be depowered, but strictly the whole system, to prevent even scheduled logging
- turning on of an incandescent light as a result of the sensor's detecting someone doing something - in which case a Shabbat mode which would preclude operation of the relevant rules during Shabbat should suffice
- turning on of an LED or florescent light as a result of the sensor's detecting someone doing something - in which case a Shabbat mode which would preclude operation of the relevant rules during Shabbat should suffice, together with ensuring there are no LEDs on the sensors chosen
That focuses on the 'work' aspect of things. It looks like the other consideration is the 'benefit' aspect. Some interpretations seem to be more permissive where actions triggered don't have any benefit to the instigator. It is hard to see how motion detection which is logged on the hub but does not trigger any change in the environment would be of benefit to the person who triggered it, again supporting a rule suppression approach.
Perhaps the OP could take the client through what is involved in the end to end process of stimulus, comms, trigger, rule execution etc to confirm exactly what is acceptable.
1 Like
You may be interested in how Predicate Conditions work in Rule 5.0. If the Predicate Conditions are established so that a rule can only run while not during Shabbat, nothing will happen during that period. There will be no triggers fired, no logic run --> nothing at all happens during that period. Instead, a scheduled event was established for the end of Shabbat which sits in the database, inactive until it is that time. At that time, the functioning of the rule would be re-established.
I should note that this use of Predicate Conditions had not occurred to me, and that there may need to be a slight enhancement to the conditions it supports, as Shabbat can be longer than 24 hours. There are conditions for between to dates, and between two times, but not for between one date at a specific time, and another date at some other specific time. I will look into adding this possibility for the next release.
Also, the ability to disable/enable a device has been added to Rule Machine for the next release.
7 Likes
Thanks Bruce.
I just tried the approach that @Hasty1 suggested, and it also works.
From Rule Machine, you can set a given id to be disabled via POST.
(I assume that it's just manipulating in the UI, just like I can do manually).
However, putting it in the Rule Machine will be better, in case the device id changes, because in Rule Machine, I assume that I will be able to reference an actual Device Label.
2 Likes
The Hubitat world is so awesome!
2 Likes
Agreed. Not so long ago, @bravenel ensured that JAWS support (for the visually impaired) was added to Hubitat within a week or so of it being requested.
Their development team is very nimble!
3 Likes
