Passivly update status of recievers based on signals
Posted: Fri Mar 17, 2023 9:45 am
I have the following setup at home:
LCMR-1000 is switching on/off a lamp, most of the times this is done through a LWST-605 on the wall.
The LCMR-1000 listens directly to the LWST-605 on the wall.
In addition Automagically controls this device with the tellstick of course.
If the lamp is turned on and off via the LWST-605 on the wall Automagically will never be able to determine if the lamp is on or off in a given point in time.
I have tried to configure the LWST-605 to trigger a event in Automagically to turn on the lamp, and this actually works, and then Automagically always knows if it is on or off. But this is rather limited in real-world usage,
it is to sluggish and slow so it annoys users and also i am concered about the fact that nobody will be able to turn lights on/off if the PI is down, or booting or down for maint. e.t.c. In addition congestion of the 433-mhz airspace is allready showing, especially since users tend to press buttons on the well with only a very short delay in between.
So what i want is:
* Define in automagically what switchers are controlloing which recievers
* Listen to the LWST-605 ON/OFF signals and mark the LCMR-1000 as ON/OFF respectivly.
* Really only LISTEN and update, i am planning for a total of 120 NEXA-units, i will have enough congestion allready.
Why i want it:
* I want to turn off lights if they have been ON for X minutes
* I want to be able to measure used electricity based on this info, if i would reliably know if a light was on or off this info would be really useful
* I want to do smarter management of lighting then just using Motion-sensors that turn the lights off after Xm, controlling Lights with both motion sensors and for ex. also LWST-605 could be really useful. Then the system could avoid turning off lights via the motion-sensor that where turned on manually just seconds earlier.
Any thoughts ?
Is the current data-model even supporting this ? I can see there is something modelled in the remotes, but not sure if it is relevant for this use.
If not supported, how should it be extended ?
Other thoughts ?
LCMR-1000 is switching on/off a lamp, most of the times this is done through a LWST-605 on the wall.
The LCMR-1000 listens directly to the LWST-605 on the wall.
In addition Automagically controls this device with the tellstick of course.
If the lamp is turned on and off via the LWST-605 on the wall Automagically will never be able to determine if the lamp is on or off in a given point in time.
I have tried to configure the LWST-605 to trigger a event in Automagically to turn on the lamp, and this actually works, and then Automagically always knows if it is on or off. But this is rather limited in real-world usage,
it is to sluggish and slow so it annoys users and also i am concered about the fact that nobody will be able to turn lights on/off if the PI is down, or booting or down for maint. e.t.c. In addition congestion of the 433-mhz airspace is allready showing, especially since users tend to press buttons on the well with only a very short delay in between.
So what i want is:
* Define in automagically what switchers are controlloing which recievers
* Listen to the LWST-605 ON/OFF signals and mark the LCMR-1000 as ON/OFF respectivly.
* Really only LISTEN and update, i am planning for a total of 120 NEXA-units, i will have enough congestion allready.
Why i want it:
* I want to turn off lights if they have been ON for X minutes
* I want to be able to measure used electricity based on this info, if i would reliably know if a light was on or off this info would be really useful
* I want to do smarter management of lighting then just using Motion-sensors that turn the lights off after Xm, controlling Lights with both motion sensors and for ex. also LWST-605 could be really useful. Then the system could avoid turning off lights via the motion-sensor that where turned on manually just seconds earlier.
Any thoughts ?
Is the current data-model even supporting this ? I can see there is something modelled in the remotes, but not sure if it is relevant for this use.
If not supported, how should it be extended ?
Other thoughts ?