search

knuckleheadsmiff / homebridge-garagedoor-ryobi

Homebridge plugin for Ryobi GDO (Garage Door Opener)
4 stars 4 forks source link

Homebridge logs showing: This plugin slows down Homebridge The read handler for the characteristic 'Current Door State' didn't respond at all!. Please check that you properly call the callback! See https://git.io/JtMGR for more info. #13

Closed Mike92115 closed 3 years ago

Mike92115 commented 3 years ago

Hello,

I wanted to pass on that I am receiving the following in my logs, after updating to HomeBridge 1.3.2 (first of the 1.3 versions that I have updated to).

Could you please take a look at this? Thank you, Mike

[3/15/2021, 9:43:50 AM] [homebridge-garagedoor-ryobi] This plugin slows down Homebridge. The read handler for the characteristic 'Current Door State' didn't respond at all!. Please check that you properly call the callback! See https://git.io/JtMGR for more info. [3/15/2021, 9:43:50 AM] [homebridge-garagedoor-ryobi] This plugin slows down Homebridge. The read handler for the characteristic 'Target Door State' didn't respond at all!. Please check that you properly call the callback! See https://git.io/JtMGR for more info.

knuckleheadsmiff commented 3 years ago

Seems like a new warning that sometimes happens. Im not set up to maintain this project and am looking for someone to take it over but the code needs restructuring to fix this warning to work better asynchronously. I'm just going to leave this issue open for now. Sorry.

knuckleheadsmiff commented 3 years ago

Andy @andyedinborough, I'm wondering if when you would be interested in looking into this. Your choice, I'm just not setup to support this anymore.

I think all we need to do is in index.js make getstate and setstate immediately return the callback function and then on an asynchronous thread (set timeout or a newer API? ... my JS skills are getting dated) execute the existing functions. Also would have to change getState doIt function to not call the callback but call: accessory.garageDoorService.setCharacteristic(Characteristic.CurrentDoorState, Characteristic.CurrentDoorState[state]); My one concern is this could lead to out of order states being processed and that could be tricky to code against. Would have to keep a list of events being processed, and if a newer request to get (and separately for set) gets called would have to kill the processing of the prior event. Testing this becomes non trivial. [This would also have to be per garage door if multiple doors are on the same login? can't remember if that issue possible.] If only 1 door is supported per instance then the list could just be the last call as a global state--we'd have to clear it once it was processed.

knuckleheadsmiff commented 3 years ago

Andy, more more thing if you do look into it.

GarageCmdAccessory.prototype.pollState calls getState and expects it to return the correct value, it too would need to be reworked. pollState itself is asynchronous and will need a little rework too.

If you don't want to tackle this that's OK.

andyedinborough commented 3 years ago

Yeah, will do. I'm working on a big revamp of the code, including device discovery by implementing a platform.

knuckleheadsmiff commented 3 years ago

Oh Great! Thanks a bunch.

andyedinborough commented 3 years ago

This is resolved by #16