The Aeon Labs door/window sensor.
Re: The Aeon Labs door/window sensor.
Thanks! Is it possible to take photo's from the inside of the device?
Alexander
Re: The Aeon Labs door/window sensor.
Uhm inprinciple that is how far you normally disassemble it for mounting or replacing the battery. I have not tried to take it apart any further, I will give it a shot on thursday.
Re: The Aeon Labs door/window sensor.
Nice work Alaxander
This is one of the topics on my list..
This is one of the topics on my list..
Enver Tanriverdi | http://blog.tane.nl
Re: The Aeon Labs door/window sensor.
just interested , why are you making wires to the wireless door / window sensor.
It will make no sence to me
It will make no sence to me

Re: The Aeon Labs door/window sensor.
After you connect it to a pressure sensor , wait are you able to control then ..?
Some doorbell or....?
just interested
Some doorbell or....?
just interested

Re: The Aeon Labs door/window sensor.
No problem, but than it is better to direct you to: http://domoticaforum.eu/viewtopic.php?f=37&t=3303
The first post is already the answer
The first post is already the answer

Alexander
Re: The Aeon Labs door/window sensor.
Hi.
Garylm at zwaveworld has learned a very imported difference between Everspring and Aeon door sensor:
http://zwaveworld.com/forum/index.php?showtopic=553 (post 10/1 2010 12:52 AM)
The Everspring (here named HRDS1) only reeds its switch every 5 seconds.
Regards
Morten
Garylm at zwaveworld has learned a very imported difference between Everspring and Aeon door sensor:
http://zwaveworld.com/forum/index.php?showtopic=553 (post 10/1 2010 12:52 AM)
The Everspring (here named HRDS1) only reeds its switch every 5 seconds.

Regards
Morten
Re: The Aeon Labs door/window sensor.
Good to know about the delay found in the Everspring, that is some helpful info, thx
Re: The Aeon Labs door/window sensor.
Garylm doesn't seem to be right.
Markf at zwaves.dk has tested the FlexControl (Everspring) sensor he owns, and it reacts instantly.
11-01-2010 19:21:34 Device Update Device: Z-Wave Door/Window Sensor Status set to ON/OPEN/MOTION
11-01-2010 19:21:34 Device Update Device: Z-Wave Door/Window Sensor Status set to OFF/CLOSED/NO MOTION
11-01-2010 19:21:32 Device Update Device: Z-Wave Door/Window Sensor Status set to ON/OPEN/MOTION
11-01-2010 19:21:32 Device Update Device: Z-Wave Door/Window Sensor Status set to OFF/CLOSED/NO MOTION
11-01-2010 19:21:30 Device Update Device: Z-Wave Door/Window Sensor Status set to ON/OPEN/MOTION
11-01-2010 19:21:29 Device Update Device: Z-Wave Door/Window Sensor Status set to OFF/CLOSED/NO MOTION
11-01-2010 19:21:28 Device Update Device: Z-Wave Door/Window Sensor Status set to ON/OPEN/MOTION
Regards
Morten
Markf at zwaves.dk has tested the FlexControl (Everspring) sensor he owns, and it reacts instantly.
11-01-2010 19:21:34 Device Update Device: Z-Wave Door/Window Sensor Status set to ON/OPEN/MOTION
11-01-2010 19:21:34 Device Update Device: Z-Wave Door/Window Sensor Status set to OFF/CLOSED/NO MOTION
11-01-2010 19:21:32 Device Update Device: Z-Wave Door/Window Sensor Status set to ON/OPEN/MOTION
11-01-2010 19:21:32 Device Update Device: Z-Wave Door/Window Sensor Status set to OFF/CLOSED/NO MOTION
11-01-2010 19:21:30 Device Update Device: Z-Wave Door/Window Sensor Status set to ON/OPEN/MOTION
11-01-2010 19:21:29 Device Update Device: Z-Wave Door/Window Sensor Status set to OFF/CLOSED/NO MOTION
11-01-2010 19:21:28 Device Update Device: Z-Wave Door/Window Sensor Status set to ON/OPEN/MOTION
Regards
Morten
Re: The Aeon Labs door/window sensor.
Hi,
I recently decided to experiment with Z-Wave after about a decade with x-10 and HS.
Part of my "starterkit" is one of these Aeon D/W sensor and I'm a bit dissapointed by the results so far, so I need help to decide if this sensor is faulty or if Homeseer has a problem with it.
I noted:
- The Tamper sensor is not tracked correctly. The first time it is tripped, HS registers it as a change, good. But when the switch is back in the correct position (pushed inside), there is no change in HS status, nor in the log. When the switch is triggered again, it appears as an "alarm on" in the log, but the status in the corresponding child device doesn't change because it was never reverted to off. So right now, whatever I do with the tamper switch, the status doesn't change and the "last change" date remains the one at the first time the switch has been tripped after configuration of the device.
- This sensor is supposed to send a "keep alive" message from time to time, but so far, if left alone, no update seems to happen. So if for instance, there is a lost of sync between the state of the sensor and HS, it remains so for ever (well at least a day so far). The only way to resync is to trigger the sensor by opening and closing the window for instance.
If this is true, that would mean that if this window is never opened, the battery status will never be updated as it seems to only update when the sensor is triggered. So you would never be warned of a dead battery.
- Maybe this is due to the cycle being over a day, It is still too new to have checked that, but then you shoud be able to shorten the cycle by modifying the parameter in the device configuration. I tried, but it always revert back to what it is when you enter this page in HS, so I'm still not sure how long the cycle is.
- I wonder if HS checks for these "keep alive" messages like the RFXcom plugin does for the security devices like DS10/90's as otherwise this would rule out these sensors for security purposes.
So if anyone with a bit of experience with these sensors could tell me if all this is normal or not as I'm still in the return goods window.
Thanks,
Yves.
I recently decided to experiment with Z-Wave after about a decade with x-10 and HS.
Part of my "starterkit" is one of these Aeon D/W sensor and I'm a bit dissapointed by the results so far, so I need help to decide if this sensor is faulty or if Homeseer has a problem with it.
I noted:
- The Tamper sensor is not tracked correctly. The first time it is tripped, HS registers it as a change, good. But when the switch is back in the correct position (pushed inside), there is no change in HS status, nor in the log. When the switch is triggered again, it appears as an "alarm on" in the log, but the status in the corresponding child device doesn't change because it was never reverted to off. So right now, whatever I do with the tamper switch, the status doesn't change and the "last change" date remains the one at the first time the switch has been tripped after configuration of the device.
- This sensor is supposed to send a "keep alive" message from time to time, but so far, if left alone, no update seems to happen. So if for instance, there is a lost of sync between the state of the sensor and HS, it remains so for ever (well at least a day so far). The only way to resync is to trigger the sensor by opening and closing the window for instance.
If this is true, that would mean that if this window is never opened, the battery status will never be updated as it seems to only update when the sensor is triggered. So you would never be warned of a dead battery.
- Maybe this is due to the cycle being over a day, It is still too new to have checked that, but then you shoud be able to shorten the cycle by modifying the parameter in the device configuration. I tried, but it always revert back to what it is when you enter this page in HS, so I'm still not sure how long the cycle is.
- I wonder if HS checks for these "keep alive" messages like the RFXcom plugin does for the security devices like DS10/90's as otherwise this would rule out these sensors for security purposes.
So if anyone with a bit of experience with these sensors could tell me if all this is normal or not as I'm still in the return goods window.
Thanks,
Yves.