›
This is the forum archive of Homey. For more information about Homey, visit the Official Homey website.

The Homey Community has been moved to https://community.athom.com.

This forum is now read-only for archive purposes.

Z-Wave: AEOTec recessed door sensor Gen5 ; pair OK, but generic alarm 'always on'

aloftaloft Member
in Devices
Hi,

I've succesfully paried a AEOTec recessed door sensor Gen5 , and it seems to send -indicated by a LED on the device - that it sends Z-Wave commands, but in the Devices setting, the 'generic alarm' will continue to blink, with sensor closed or open.  There is no change in alarm , it is just always 'on'. 

Model: ZW089-C 

Is there a way to look at z-wave logs to see the messages that are coming in to Homey? Maybe that helps in determining the issue of this device not working.

I've found online some discussion on other controllers:  https://www.domoticz.com/forum/viewtopic.php?t=5099

leading to: 

https://raw.githubusercontent.com/OpenZWave/open-zwave/master/config/aeotec/recessed_doorsensor_gen5.xml

«1

Comments

  • DaneeDeKruyffDaneeDeKruyff Member
    edited March 2016
    Check out the 2nd post Taco made on page 3 in this thread about the aeotec devices: https://forum.athom.com/discussion/875/version-0-8-20/p3
  • aloftaloft Member
    @DaneeDeKruyff  I've set the 121,4,16 parameter, but still not available. that is consistent with @mruiter 's observation too after applying the parameter. 

    But I am not sure the parameter is succesfully synced with the device; I am not sure the device wakes up. It sometimes reports battery level (as reported in 'insights'), but not everytime I wake up the device. 
     
  • mruitermruiter Member
    the parms dont work or just dont get sync. i cant tell withnthe limited homey interface en comfig options.
    Just like the multisensor. and the doorsensor they just dont do what there capapable off or should do.
    The door sensor is just a simple binair on off for the alarm. Just like jou i just gat a constant alarm blonk on it as soon as its paired.

  • DaneeDeKruyffDaneeDeKruyff Member
    Hmmm that's too bad, I have those sensors too, sure hope this will be fixed soon.
  • mruitermruiter Member
    I hope to have time to play with it some more this weekend. Im starting to get the hang of it.
    Got the motion sensor to work on the multisensor. :)
    boot is looks like i can only send 2 pairs op parm setting. Last night i gave error when i tried 3 or more to set up humidity and some montion detection tweaks in the parm line
  • aloftaloft Member
    I am interested in the results especially on the door sensor; I think I tried every trick in the book to get the device working correctly, but either it doesn't receive/accept the parameters, or Homey interprets the trigger signal wrong. 

    I suspect the paramters aren't sent to the device, I have the same issue with an Everspring device; the parameters settings are not used; the Everspring device will react on changes in the Wake-up timer.
  • mruitermruiter Member
    aloft said:

    I suspect the paramters aren't sent to the device, I have the same issue with an Everspring device; the parameters settings are not used; the Everspring device will react on changes in the Wake-up timer.
    That were my thoughs also. Looks like the device does not get the parms. Wake up command by pressing the button 5 seconds and then safe or wait unit device wakes up make no difference.

    @Taco any idea's . Maybee there comes a debug or a status windows anytime soon ?
  • mruitermruiter Member

    Had a few minutes an tried to test more thing. I'm giving up. Z-waves to buggy.

    Remove node just crashes Homey when presenting device. Reset zwave chip reboot homey all the same.

    Only a full restore to default will be the sollution i guess.

    I'm not going to do this "again" for the so manyiest time.

    Please make a config backup and restore option the high priority on your lists ! With all the restore do defaults is never gona be something else then a disaster waiting to happen . A reset to default means bye bye for my 35 flows.

    Not gonna happen even if half of them crash all the time.

  • TacoTaco Member
    Could you please send us the logs after a crash and PM me the given code? Then I can see what went wrong and fix it.

    If you press the Reset Z-Wave Network button only the Z-Wave module will be reset and your Z-Wave devices will be removed from Homey. All you flows are kept.
  • aloftaloft Member
    @Taco  I did try to remove this suspended sensor device, Z-Wave page became unresponsive, and even the whole Z-wave system became unresponsive (other devices didn't work anymore). 

    I tried sending a crashlog, this was the result instead of a number "stdout maxBuffer exceeded". 

    So I am not sure it was received. 


  • mruitermruiter Member
    Same here buffer errors . complete system hangy hangy so log sending not possible
  • TacoTaco Member
    edited March 2016
    Could you reboot, reproduce the problem and send log.
  • aloftaloft Member
    I've made some progress:

    * Parameters get synced when you manually wake up the device (1 push on the z-wave button) 
    * When door is closed, and I manually sync the device by pushing the z-wave button, alarm goes off
    * When I open door, the device LED lights up. But Homey doesn't receive/process the command
    * When I manually wake-up the device again, Homey registers the state (door open) and triggers the alarm
    * Changing polling/wake-up intervals (and updating via manual wake-up) don't change this behaviour. So device doesn't wake-up automatically.

    So my conclusion: Somehow the device is sending the trigger, but this isn't received/processed by Homey. Homey does understand (with the 121,4,16 parameter) what the state of the sensor, but only after a manual wake-up.

    For the complete picture: I've resetted the whole Z-wave network and included the sensor again. Not sure if this made a difference. 
  • TacoTaco Member
    We are aware of a bug where the settings aren't applied when you press save the first time after you've added the device. To workaround this bug enter any setting, press save, enter the setting you want to change/apply. You only have to do this once after the device is added.
  • mruitermruiter Member
    edited March 2016
    Taco said:
    We are aware of a bug where the settings aren't applied when you press save the first time after you've added the device. To workaround this bug enter any setting, press save, enter the setting you want to change/apply. You only have to do this once after the device is added.
    tried that even punched more then ten times save and wake up device .no results
    homey does not understand what the senors is talking on the zwave
    Homey just gives an constant alarm on the device no matter what
  • aloftaloft Member
    mruiter said:
    Taco said:
    We are aware of a bug where the settings aren't applied when you press save the first time after you've added the device. To workaround this bug enter any setting, press save, enter the setting you want to change/apply. You only have to do this once after the device is added.
    tried that even punched more then ten times save and wake up device .no results
    homey does not understand what the senors is talking on the zwave
    Homey just gives an constant alarm on the device no matter what
    Did you try my way of working? If you simulate closing the door and then waking up the device by pressing the z-wave button, the alarm will stop.
     
    I am testing with a sensor that isn't built-in a door or window yet, you need to be able to reach the z-wave button with the magnet 50 % on the device. 

  • aloftaloft Member

    Taco said:
    We are aware of a bug where the settings aren't applied when you press save the first time after you've added the device. To workaround this bug enter any setting, press save, enter the setting you want to change/apply. You only have to do this once after the device is added.
    OK, but this doesn't explain yet for this specific device: not reacting on the signal without a manual wake-up.   Homey _can_ interpret the signal (as it does with the manual wake-up), but it doesn't process it correctly when the device sends it on a trigger basis.
  • mruitermruiter Member

    Well, today i got my AEOTEC Smart Switch 6 plugs in , so i thought "A well, lets give it another try"

    Did Z-wave reset.... Reboot Homey Afterwards (Becaus zWave gave 15 minutes after the reset still Zwave not available) And the Z-wave was fresh.

    Did the magic, add device - zwave - Push button and then ....... Ofcourse, what else ... Complete Homey Crash and shutdown.

    @Taco i send my logs to you with number 10A501916F

    I hope you see something because Z-wave is to no use for me. Kaku is crashing all the time... Somfy RTS is making everything else crash.... I'm running out of devices to control. Hue is useless because Homey does not now Sunrise Sundown yet.

    Hey,,, At least my irobot Roomba cleaned the house this morning at 4:30 (That worked :) )

    Hope youll find somethings

  • mruitermruiter Member
    edited March 2016
    And after 15 minutes of doing nothing Homey locked up completly again......

    Just for comparison purposes i send the updated log again with the new out of the blue crash of z-wave under number CBB32D5963


    Nother update: Complete reset to default. So complete Homey back to basic. Bye bye all flows and settings and devices :( (When will the backup function be there ? )

    Only and first thing after complete reset... Add Z-wave device.. Push button, Found Device, Interview....... Complete system crash. So AEOTEC Smart Switch 6 also makes Z-wave go bye bye for ever
  • mruitermruiter Member
    Also got the Fibaro smoke sensor.
    Was able to add that device. Shows Smoke Alarm, Fire Alarm, Temp and Battery.
    But just like the door sensor the Generic Alarm is Always on and can't be shut up.

    So this device is also alway in a stat of alarm.
  • TacoTaco Member
    Thnx for sending the logs. I'll take a look at them monday.

    If a capability is assigned to a device (you see it in the card) it is always updated when the devices reports its status. This is certain because during the interview the same frame is used to assign the capability as to update it. This means the device isn't sending reports. The always flashing is because during the interview the alarm was active.

    With the smoke sensor the generic alarm is mapped to the tamper alarm (association group 2 from the top of my head).
  • aloftaloft Member
    @Taco  , does this mean you are clainming the Gen5 sensor (door sensor) isn't sending its reports, only when I wake it up?  I am pretty sure it is sending a report when the door is opened.

    During the initial interview, it will not use the binary frame, so I am not sure your statement is correct.

    I'd like to see a way to look at the incoming Z-Wave logs; I have provided all possible logging and scenarios testing I can do without access to the logfiles. I understand Athoms view to keep the platform not too much open, but this way I cannot help making this platform as stable as possible. 

    There are at least two users with this problem, so the chance that both have faulty sensor devices are pretty low in my opinion. 

  • TacoTaco Member
    edited March 2016
    In the logs I can see if there are Binary Reports being received but until I can take a look at them I'm not making statements.

    I do think the device isn't sending reports but I can't be certain yet. There might also be a bug when parsing the report I haven't been able to reproduce so far, but for now it is just speculation.

    During the interview all mutually supported command classes are interviewed, so also Binary Sensor.
  • mruitermruiter Member
    I have 5 of these door sensors. you can skip te part thats is broke because i tried it with multiple. :) 
  • aloftaloft Member
    Taco said:
    In the logs I can see if there are Binary Reports being received but until I can take a look at them I'm not making statements.

    I do think the device isn't sending reports but I can't be certain yet. There might also be a bug when parsing the report I haven't been able to reproduce so far, but for now it is just speculation.
    OK, I'll will do some testing, note down the exact actions and timings I executed, and then send the logfiles and PM you the number, so you can have a look at your earliest convenience. 

    Still, read-only access to the logfiles myself would help me and Athom ;-)  Please discuss internally if this is somehow possible for people who'd like to help getting devices supported.  I understand you are all swamped in work, so if this can be offloaded to the Homey users to get more detailed bug-reports, that might help your cause.

    Thanks!
  • aloftaloft Member
    mruiter said:
    I have 5 of these door sensors. you can skip te part thats is broke because i tried it with multiple. :) 
    Can you also confirm the status is updated when you press the 'z-wave button' inside the device? When I do that, status is updated (and parameters get synced, e.g. 1,1,1 to reverse the alarm ( door open => alarm off ) . 1,1,0 to go back to the default state. And of course 121,4,16 to get binary reports.
  • mruitermruiter Member
    i think i alread tried that procedure and didnt work for me. Maybee i have some time tomorrow. Today i wanted to get the basic wall outlet plug swith to work aeotec smartswitch but those completely hang up z-wave and after a reboot and a wait for a few minutes homey get stuck, slow an zwave killed again.
    Im thinking to wait for the next update firmware. i hate to de a complete reset to default every time and no restore function for learned devices and flows.
  • aloftaloft Member
    OK, Hopefully you can retest. I am curious to know if you experience the same issues. That might help @Taco  in determining the cause of this bug.  What I read on-line is that other platforms are supporting the sensor, so we should be able to get this working in Homey, and monitoring doors and windows without ugly-looking devices in sight ;-)
  • aloftaloft Member
    All times in Zulu:

    Sensor node ID: 5
    Current parameters: 101,1,1;111,4,240;121,4,16;1,1,0

    Closed = magnet on switch
    Open = magnet off switch

    doorsensor ‘closed’ 
    09:56 : reboot Homey
    09:58 : generic alarm off ; as expected  ( last state )
    09:59 : door open ; LED on device ON for 3-4 seconds; no status change in Homey
    10:00 ; pushed z-wave button on device  ; LED on device ON for 3-4 seconds ; status change in  Homey -> generic alarm on
    10:01 ; door closed; LED on device ON for 3-4 seconds; no status change in Homey
    10:02 : pushed z-wave button on device  ; LED on device ON for 3-4 seconds ; status change in  Homey -> generic alarm off
    10:03 : change parameters to: 101,1,1;111,4,240;121,4,16;1,1,1 
                                       - reverse open/door status
                no change in status ( as expected, parameters not synced yet)
    10:04 : push z-wave button on device (doorsensor still closed): LED on device ON for 10 seconds; status change in  Homey -> generic alarm on
    10:05 : door open ;LED on device ON for 3-4 seconds; no status change in Homey
    10:06 : pushed z-wave button on device  ; LED on device ON for 3-4 seconds ; status change in  Homey -> generic alarm off
    10:07 : Crashlog: 6D3FCD377D
  • aloftaloft Member
    @Taco ;analysed the data and found that somehow not all parameters are sent/accepted, including the necessary 121 parameter.  So when the door open/closed, the sensor still sends the Basic Set Frames instead of a Binary Set. During the wake-up, Homey asks for a status report and that's when the status is correctly sent to Homey

    It is still unclear what causes the not sending/accepting of the 121 parameter. Testing continues...
Sign In or Register to comment.