Jump to content
C4 Forums | Control4

C4Happy

c4Forums Member
  • Posts

    17
  • Joined

  • Last visited

Posts posted by C4Happy

  1. I have a YRD226-C42-619 with the AYR202-ZB-C4 module.

    Project has an HC250 controllers. Patched to 2.10.6.561784.

    Long story short - I had an older Yale lock that has worked perfectly for likely 8 years.  Module failed.

    So bought a new Yale YRD226 with Control4 Zigbee Module.

    It adds to the project with no issue.

    I can get notifications of manual lock and unlock (through programming of events.)  

    Within 1 foot of lock is a LSZ-101 switch that controls the lights in the area of the entrance door.

    Also within this space is a motion sensor that is connected for future alarm purposes but more so I have events that run that turns on the entrance lights.

    Beyond the entrance is 3 more LSZ-101 switches that are basically 15 feet away from Door lock.

    So everything else in the project works fine.  No delays, no anomolies.

    So now to the issue at hand,  As mentioned the lock reports back to composer with its lock/unlock status. However I cannot use C4 to lock or unlock. I am using the driver  yale-control4-3.c4z which is the newest available.

       

    Name:    Yale Smart Locks

    Proxy:    lock
    Manufacturer:    Yale
    Model:    Assure, nexTouch, Doorman
    Creator:    Yale
    Control Method:    zigbee
    Certified:    Yes
    Creation Date:    06/07/2021 04:20 PM
    Modified Date:    07/02/2021 03:46 PM
    Version:    28
    Device ID:    983
    Proxy ID:    984
    Device File:    yale-control4-3.c4z
    Proxy File:    lock.c4i

    So out of the blue on 3 occasions in the last year it will suddenly start working to lock and unlock and all control functions.  It works until I have an event such as a power outage or a controller reboot.

    In terms of interference I have an AP in the Basement approx 20 feet from the entrance door above.

    I have the 2.4 Channel down low and the Zigbee channel at 25 so no interference.

    I have even shut off the wireless for testing and no difference.

    I have even taken the lock out of the door and placed it in the middle of my house where there is definitely no concern of range or similar.

    Thanks for any suggestions.  I have rebooted the lock(pulling batteries for hours at a time), wiped the lock and driver from my project, factor reset the lock many times and no change in behaviour.

    The lock/driver is supposed to be compatible with the OS on my controller.

     

    The strange thing is just out of the blue it starts working flawlessly.  It seems when it starts working it gets all the outstanding tasks as it will go through a lock unlock cycle for a while.  (I have nightly tasks for locking door so that would explain the catch up on events)

     

    Thanks for any suggestions.  I don't think it has anything to do with interference and nothing in my project has changed prior to the lock replacement.   The old lock worked flawlessly until the module failed, so if interference etc it should have happened somewhere in the 8 years with the old lock.

     

     

    Under the Driver Tab under LUA I get errors such as 

    Task Failed: name[set_time_zone] id[90]
    Canceling task: name[set_dst_shift] id[89]. Task not run because previous necessary tasks failed.
    Canceling task: name[set_time] id[88]. Task not run because previous necessary tasks failed.
    Canceling task: name[get_date_time] id[87]. Task not run because previous necessary tasks failed.
    Invoking task: name[end_super_procedure] id[86] (3 in queue)
    Super Task Failed: name[sync_date_time] id[38]
    Re-queueing task (0 retries left).
    Task Queue Insert: name[sync_date_time] id[38]
    Task Succeeded: name[end_super_procedure] id[86]
    Invoking task: name[sync_date_time] id[38] (3 in queue)
    Task Queue Insert: name[end_super_procedure] id[91]
    Task Queue Insert: name[get_date_time] id[92]
    Task Queue Insert: name[set_time] id[93]
    Task Queue Insert: name[set_dst_shift] id[94]
    Task Queue Insert: name[set_time_zone] id[95]
    Super Task Start: name[sync_date_time] id[38]
    Invoking task: name[set_time_zone] id[95] (7 in queue)
    ZL.logPacketTransmission(): class[Outbound] frameType[Global] clusterId[0x000a][Time] commandId[0x02][WriteAttributes] sequenceNumber[0x16]
    ZL.logPacketTransmission(): class[Outbound] frameType[Global] clusterId[0x000a][Time] commandId[0x02][WriteAttributes] sequenceNumber[0x16]
    Task timed out.
    Task Failed: name[set_time_zone] id[95]
    Canceling task: name[set_time] id[93]. Task not run because previous necessary tasks failed.
    Canceling task: name[set_dst_shift] id[94]. Task not run because previous necessary tasks failed.
    Canceling task: name[get_date_time] id[92]. Task not run because previous necessary tasks failed.
    Invoking task: name[end_super_procedure] id[91] (3 in queue)
    Super Task Failed: name[sync_date_time] id[38]
    Task Succeeded: name[end_super_procedure] id[91]
    Invoking task: name[unlock] id[59] (2 in queue)
    ZL.logPacketTransmission(): class[Outbound] frameType[ClusterSpecific] clusterId[0x0101][DoorLock] commandId[0x01][UnlockDoor] sequenceNumber[0x17]
    ZigBee Details: disableDefaultResponse[false] manufacturerSpecific[false] manufacturerCode[] direction[ToServer] profileId[0x0104] sourceEndpoint[1] destinationEndpoint[1] packet[01 17 01] payload[]
    ExecuteCommand(LUA_ACTION)
    .   ACTION:  getBasicAttributes
    Task Queue Add: name[get_basic_cluster_attributes] id[96]
    Task timed out.
    Task Failed: name[unlock] id[59]
    Re-queueing task (3 retries left).
    Task Queue Insert: name[unlock] id[59]
    Invoking task: name[unlock] id[59] (3 in queue)
    ZL.logPacketTransmission(): class[Outbound] frameType[ClusterSpecific] clusterId[0x0101][DoorLock] commandId[0x01][UnlockDoor] sequenceNumber[0x18]
    ZigBee Details: disableDefaultResponse[false] manufacturerSpecific[false] manufacturerCode[] direction[ToServer] profileId[0x0104] sourceEndpoint[1] destinationEndpoint[1] packet[01 18 01] payload[]

     

     

    Thanks in advance for suggestions as I am ready I think to abandon this lock with a C4 controller and perhaps buy the optional Zwave module and use Google Home to control it.

    Take care

  2. Hello Everyone

    I purchased a Yale real living lock with the Zigbee module from a Control4 dealer.

    • Apprentice
    • c4Forums Member
    I installed a new Yale lock - YRD226-C42-619  into a 250 controller project - 2.10.6.

    I have the yale-control4-3.c4z driver as shown on the C4 website - Control4 Driver Search

    It identifies to the project with no problem and is connected to the General Control 4 relaysingle_doorlock_c4.c4i 

    The lock does provide feedback to composer showing its status as locked or unlocked

       

    image.png.f350e3814baaddda741ebd495eb14ae7.pngimage.png.5da58d9ca2b03822a594acaef21159d7.png

    However I cannot control the lock using composer or the Android Lock.

    I have done a device reset and removed everything from the project and re-added but no change.

    My old Yale locks works when I re-add it to my project (but it has issues with battery drain and hence my reason for changing it)

    Is there anyone out there that has placed this model with the Control4 Zigbee module on at 250 controller running 2.10.6?

    Thanks everyone for your time reading this.

  3. 10 hours ago, Jeffrobinson1327 said:

    unplug your controller for 5 minutes.  then plug it back in.  give it 15 minutes for everything to come back to life before you try it again.  Locks can be finicky.  I just had this issue with my my only yale lock. (although i just helped another with this issue only it was kwikset.)  it showed feedback but the system would not lock/unlock.  Do the full power off of the controller though, a simply reset often won't work.  Let us know if this works.

     

    Jeff

     

     

    Thanks for your response.

    I unplugged it for over 30 minutes.  Fired it back up but unfortunately it behaves the same.

     

    It would really appear to be perhaps a faulty Zigbee module.   I haven't found any other driver other then the one I am using.   

    I have contacted the dealer to see if they can find a service bulletin or similar on the C4 site, but they haven't returned my call with any news yet.

     

    Take care

  4. 20 hours ago, Dueport said:

    No problem.  You may want to try checking the firmware version on the lock itself to confirm it is compatible with the driver.  I posted something about an issue I had with a lock that I think is older than the one you're having trouble with so this may not be the issue but worth checking.  Here's that post for reference:

     

    Thanks for your response.  Actually my old lock the Yale Real living had this exact thing.  I had updated the firmware and broke it, so had to downgrade the firmware to 2.7   Worked great after that until this year.  It started going through a set of batteries in 1 month.   Close proximity and nothing had changed within my house.  Appears to be a zigbee module issue in the old one.   I will have to see about a possible other firmware version available.

     

    Take care

  5. 4 hours ago, Dueport said:

    What model Yale lock is this?  I see that your "Module Firmware Version" and "Hardware Version" fields are not populating.  When that happened with my Yale Assure 2 locks I needed to use the Yale app to connect via bluetooth to the lock and update the firmware.  Then I used the module firmware update under the driver actions tab and, with both of those firmwares updated I didn't have any more issues.  I'm running 3.3.2 though so it may not be this but worth considering

    Thanks for your response.   Mine is just the Yale Assure so I cannot pair with Bluetooth.

    I noticed that part also as my old Lock Yale Real Living does fill in all that info.

    The only driver I can find online is what I installed.  I am leaning towards an issue with the Driver, but until I can find any evidence of a newer one I suspect that is all I can get.

     

    Take care

  6. I installed a new Yale lock - YRD226-C42-619  into a 250 controller project - 2.10.6.

    I have the yale-control4-3.c4z driver as shown on the C4 website - Control4 Driver Search

    It identifies to the project with no problem and is connected to the General Control 4 relaysingle_doorlock_c4.c4i 

    The lock does provide feedback to composer showing its status as locked or unlocked

       

    image.png.f350e3814baaddda741ebd495eb14ae7.pngimage.png.5da58d9ca2b03822a594acaef21159d7.png

    However I cannot control the lock using composer or the Android Lock.

    I have done a device reset and removed everything from the project and re-added but no change.

    My old Yale locks works when I re-add it to my project (but it has issues with battery drain and hence my reason for changing it)

    When doing debugging in Lua it does show results but not conclusive to issues.

    I have a custom button programmed to lock or unlock with the Android App

     

    ReceivedFromProxy(): LOCK on binding 5001; Call Function PRX_CMD.LOCK()

    PRX_CMD.LOCK
    LockDevice:PrxLock
    LockCom_Lock
    Task Queue Add: name[lock] id[16]
    Task timed out.
    Task Failed: name[lock] id[14]
    Re-queueing task (0 retries left).
    Task Queue Insert: name[lock] id[14]
    Invoking task: name[lock] id[14] (3 in queue)
    ZL.logPacketTransmission(): class[Outbound] frameType[ClusterSpecific] clusterId[0x0101][DoorLock] commandId[0x00][LockDoor] sequenceNumber[0x1f]
    ZigBee Details: disableDefaultResponse[false] manufacturerSpecific[false] manufacturerCode[] direction[ToServer] profileId[0x0104] sourceEndpoint[1] destinationEndpoint[1] packet[01 1F 00] payload[]
    Task timed out.
    Task Failed: name[lock] id[14]
    ZL.logPacketTransmission(): class[Outbound] frameType[ClusterSpecific] clusterId[0x0101][DoorLock] commandId[0x00][LockDoor] sequenceNumber[0x20]
    Invoking task: name[lock] id[15] (2 in queue)
    ZigBee Details: disableDefaultResponse[false] manufacturerSpecific[false] manufacturerCode[] direction[ToServer] profileId[0x0104] sourceEndpoint[1] destinationEndpoint[1] packet[01 20 00] payload[]
     

    Does anyone have any suggestions on what I may have overlooked?

     

    Thanks everyone for your time reading this.

  7. Well I got my system back up and functional.

    After much trying different scenarios I had a corrupted Cert on my controller.

     

    I had a spare brand new HC250 and I patched it to the same level and started comparing certs.  (Based on error 400 I was seeing.) 

    I ended up doing a factory restore and patched it back and then restored my project.

     

    All is working, checkin is fine, connection to 3rd party apps.

     

    Thanks everyone for your suggestions and huge thanks out to @chopedogg88for assistance on the first night.

     

    Take care all.

     

  8. 16 minutes ago, mstafford388 said:

    If that dealer is cut off by control4 the systems that are registered to that dealer go off into a black hole never to be seen or heard from again.  It's not quite that bad, but they do get put in a no dealer queue that isn't much better.   On top of that your son's credentials would be cut off.  You need to get this thing registered to an active dealer. 

    I had assistance last night from a current C4 installer.   Controller was removed from my account and we tried re-registering but no luck.

    Getting an error of 

    Controller is not registered
    Registering controller...
    Controller is not registered
    Error while communicating with the Web Services.  Fault = The remote server returned an unexpected response: (400) Bad Request. LSE = 0
    No response to check-in request.  VPN connection may be invalid.

    400 is usually a Web Cert Error is it not?

     

    Take care

     

  9. 27 minutes ago, chopedogg88 said:

    Try using System Manager.  Connect to the HC250, then go to the Setup tab, and under VPN Host dropdown, select Production.  This will reboot the HC250 after you select it.  See if that fixes it.

    I tried that.  Now when trying the update manager I got rid of the soap error.

    Successfully obtained update version information from web service: 1 update version(s) available
    All devices are either up to date or are not currently online. Aborted the update.

    Previously it said Update authorization failed. Failure reason (12): "SOAP fault"

    Checked the C4 page and it still shows

    • Activated on 3/31/2013 8:04:24 PM
    • Checked-in on 8/20/2021 8:10:08 PM
    • Smart Home OS 2.10.6

    Thanks for your suggestion.

     

  10. 2 minutes ago, chopedogg88 said:

    Have you tried simply power cycling the controller?

    Thanks for your response.  I have recycled it a number of times but to no avail.  The strange thing is I have not done a change to this for likely a few months, so nothing to correlate why it won't check in since Friday.

     

    Take care

  11. Hello All
    Just 3 days ago my HC250 stopped checking in to C4.   This has a valid Insight license.

    As a result now Alexa can not communicate to my system.

    I am running 2.10.6.561784 since it became available.

    Because the HC250 won't upgrade past this I cannot patch any further.

    The controller is verified by myself to have Internet connectivity.  I putty into the controller and can ping 4.2.2.2 

    Tried DNS resolution and it also works fine.
    I am using 8.8.8.8 and 8.8.4.4 for DNS servers.

    My C4 app on my phone works fine locally but not remotely because of the checkin issue.

    When I try to run Update Manager it says
    Successfully obtained update version information from web service: 1 update version(s) available
    Update authorization failed. Failure reason (12): "SOAP fault"

    The update URL is http://services.control4.com/Updates2x/v2_0/Updates.asmx

    Composer connects fine.  Networking is my Full time job so I can say with Certainty that my network is fine.


    Any suggestions of what could possibly be the problem. Thanks for assistance that you may be able to provide.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.