search

sebmos / node-eufy-api

A simple JavaScript API to control EufyHome (Anker) smart light bulbs, switches and plugs.
Apache License 2.0
22 stars 7 forks source link

Devices added then immediately removed #2

Open rodalpho opened 5 years ago

rodalpho commented 5 years ago

The plugin installed fine, but from the log, it appears to find my devices and then immediately remove them. Any idea what's going on? Nothing weird in my config file either, just added the plugin with my EufyLife login.

I replaced the IDs in the log with <> just in case that's a security issue. 

[2/7/2019, 8:44:22 AM] [Eufy] Add Accessory: Bedside Light - <<alphanumeric string>>
[2/7/2019, 8:44:22 AM] [Eufy] Add Accessory: Living Room Right Wall Light - <<alphanumeric string>>
[2/7/2019, 8:44:22 AM] [Eufy] Add Accessory: Living Room Left Wall Light - <<alphanumeric string>>
[2/7/2019, 8:44:22 AM] [Eufy] Add Accessory: Living Room Standing Light - <<alphanumeric string>>
[2/7/2019, 8:44:22 AM] [Eufy] Removing accessory: Bedside Light
[2/7/2019, 8:44:22 AM] [Eufy] Removing accessory: Living Room Right Wall Light
[2/7/2019, 8:44:22 AM] [Eufy] Removing accessory: Living Room Left Wall Light
[2/7/2019, 8:44:22 AM] [Eufy] Removing accessory: Living Room Standing Light
sebmos commented 5 years ago

Hey @rodalpho,

It looks like there's a problem with the device support for the devices you're using. The easiest way to help me resolve this would be if you could do the following: Can you check out the node-eufy-api repository, and run the command-line interface to log in to Eufy and connect to one of your devices? It will probably fail, but if you could then provide me with the bash output, that'd be great.

I'm particularly interested in any error messages (but seeing the instructions in between would be helpful), as well as the device codes.

rodalpho commented 5 years ago

I'd be happy to, if you can tell me what to run. They're all this bulb:

https://smile.amazon.com/gp/product/B0784WDQJB/

sebmos commented 5 years ago

Hey @rodalpho,

Thanks - can't figure out what model it is from there, unfortunately. Running the command-line interface should help, though.

Please do the following steps outside the current homebridge setup:

git clone git@github.com:sebmos/node-eufy-api.git
cd node-eufy-api/
npm install
npm run cli

This should get you to the command-line interface, where you can sign in with your username/password, which should list your devices. From there, follow the instructions and check if you can select, then turn on/off, or change the colour temperature (if that is supported) one of the bulbs. You will most likely get an error very early on, when that happens, post the whole output here. (Feel free to redact IP address & code, but please not the model.)

rodalpho commented 5 years ago

Sorry, those commands didn't work. I cloned the git repo with "git clone https://github.com/sebmos/node-eufy-api.git", but then after the install npm run cli complained about missing 'node lib/cli.js'. Then I tried to install with npm install node-eufy-api --save, it installed, but then complained about missing package.json. Running it in the directory I had cloned earlier gave the same missing cli.js error. If you can provide an exact sequence of commands to run that will work, I'm happy to give it another shot. I am a competent sysadmin but don't know node at all.

sebmos commented 5 years ago

Apologies, I forgot to add to run ‘npm run build’ after running ‘npm install’

Can you do that and then try running the cli again?

rodalpho commented 5 years ago

Yep, all set. All four lights are model T1011.

sebmos commented 5 years ago

That’s useful, thanks.

Did you try and turn one of the devices on/off? Could you post the bash output from running that, including any error messages you receive?

Also, there are a few Troubleshooting steps listed here: https://github.com/sebmos/node-eufy-api/blob/master/README.md#troubleshooting Can you just double-check them?

rodalpho commented 5 years ago

When I select one of the lights I just get an error:

(node:29674) UnhandledPromiseRejectionWarning: AssertionError: Assertion failed
    at new goog.asserts.AssertionError (/tmp/node-eufy-api/node_modules/google-protobuf/google-protobuf.js:98:603)
    at Object.goog.asserts.doAssertFailure_ (/tmp/node-eufy-api/node_modules/google-protobuf/google-protobuf.js:99:126)
    at Object.goog.asserts.assert (/tmp/node-eufy-api/node_modules/google-protobuf/google-protobuf.js:99:385)
    at jspb.BinaryWriter.writeInt32 (/tmp/node-eufy-api/node_modules/google-protobuf/google-protobuf.js:277:264)
    at Function.proto.lakeside.T1012Packet.serializeBinaryToWriter (/tmp/node-eufy-api/lib/lakeside_pb.js:1331:12)
    at proto.lakeside.T1012Packet.serializeBinary (/tmp/node-eufy-api/lib/lakeside_pb.js:1315:30)
    at LightBulb.<anonymous> (/tmp/node-eufy-api/lib/device-base.js:207:77)
    at step (/tmp/node-eufy-api/lib/device-base.js:32:23)
    at Object.next (/tmp/node-eufy-api/lib/device-base.js:13:53)
    at /tmp/node-eufy-api/lib/device-base.js:7:71
(node:29674) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 3)
(node:29674) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

What troubleshooting are you talking about? Unplugging/replugging the bulbs, pinging them? I can ping them from that same server, it isn't a network issue.

sebmos commented 5 years ago

Ok. I take it restarting (unplugging/replugging) the light bulb didn’t solve the problem, either?

rodalpho commented 5 years ago

Right, did not fix it.

sebmos commented 5 years ago

Thanks for confirming that, and for your patience so far!

I have an idea of what the problem is, but will have to spend some time trying to reproduce it. I'll let you know when I know more!

rodalpho commented 5 years ago

No problem, appreciate it!

sebmos commented 5 years ago

Hey @rodalpho,

I published a new version of the package that adds a verbose logging option, which should provide me with a lot more information on what the error is. Can you pull the latest changes, re-build the library and then run the command-line using the following commands:

git pull
npm run build
npm run cli:verbose

You will notice that this will write a lot of information to the console. Could you copy all of it, and post it here? Alternatively, feel free to send me an email to sebastian.moser@gmail.com

rodalpho commented 5 years ago

Is the verbose mode working? It didn't write that much debug info.


root@pihole:/tmp/node-eufy-api# npm run cli:verbose

> node-eufy-api@0.0.6 cli:verbose /tmp/node-eufy-api
> node lib/cli.js --verbose

? Eufy account email address <<removed>>
? Eufy account password [hidden]
Logging in
Loading devices
(AbstractDevice.new) Create device (model: T1011, code: E095B5767FF24402)
(AbstractDevice.new) Create device (model: T1011, code: 5ADE6C4EB58B4268)
(AbstractDevice.new) Create device (model: T1011, code: 0860BE8D806B40E2)
(AbstractDevice.new) Create device (model: T1011, code: CD19BE0E23E84B61)
Logged in, devices loaded
? Save credentials locally for future use? Yes

? Choose device Bedside Light (Model: T1011, Code: E095B5767FF24402, IP Address: 10.10.20.39)
(AbstractDevice.connect) Connecting
(TcpSocket.connect) Connecting at 10.10.20.39
(AbstractDevice.new) TCP Socket connected
(AbstractDevice.connect) Connected to device Bedside Light (Model: T1011, Code: E095B5767FF24402, IP Address: 10.10.20.39)
(AbstractDevice.connect) Loading current device state
(LightBulb.loadCurrentState) Loading current device state
(LightBulb.getState) Loading current device state
(AbstractDevice.getSequence) Loading current sequence number
(AbstractDevice.sendPacketWithResponse) 1156188,E095B5767FF24402,0
(AbstractDevice.sendPacketWithResponse) Response received: {"type":"Buffer","data":[8,210,120,168,121,220,215,186,163,27,151,199,55,213,6,105]}
(AbstractDevice.sendPacketWithResponse) Response decrypted: {"type":"Buffer","data":[12,0,8,162,132,234,176,10,18,0,26,2,8,1,0,0]}
(AbstractDevice.sendPacketWithResponse) Deserializing response as T1012Packet
(AbstractDevice.getSequence) Current sequence number: 2786755106
(LightBulb.getState) Sending request to device
(AbstractDevice.sendPacketWithResponse) 2786755107,E095B5767FF24402,,,1
Error connecting to device: AssertionError: Assertion failed
sebmos commented 5 years ago

This is exactly the info I need, thanks. It confirms what I assumed, which is that it appears to be the same as this issue: https://github.com/google/python-lakeside/issues/11

Another question: Can you verify what firmware version you're on? (You can do that in the EufyHome app.) If a firmware update is available for your light bulbs, could you install that and try again? (At least on one of the devices.)

rodalpho commented 5 years ago

Yes, I'm running version 2.6. No updates are available.

sebmos commented 5 years ago

OK. So, this appears to be related to the issue linked above, https://github.com/google/python-lakeside/issues/11. It happens, because the protobuf file taken from the python-lakeside library specifies the "sequence number" to be of type int32, and the value it's trying to set for your device is higher than that.

I'm not sure if this int32 classification is intentional or not - to verify, I've changed it to int64 on a branch. If that works for you, I can merge that change into the main branch.

To test this version, please run the following set of commands:

git checkout --track origin/sequence-number-bug
npm install
npm run build:clean
npm run build
npm run cli:verbose

In the future, you can switch between the master and the bug-branch using git checkout master and git checkout sequence-number-bug.

rodalpho commented 5 years ago

Still get an error, output is below.

root@pihole:/tmp/node-eufy-api# npm run cli:verbose

> node-eufy-api@0.1.0 cli:verbose /tmp/node-eufy-api
> node lib/cli.js --verbose

Logging in
Loading devices
(AbstractDevice.new) Create device (model: T1011, code: E095B5767FF24402)
(AbstractDevice.new) Create device (model: T1011, code: 5ADE6C4EB58B4268)
(AbstractDevice.new) Create device (model: T1011, code: 0860BE8D806B40E2)
(AbstractDevice.new) Create device (model: T1011, code: CD19BE0E23E84B61)
Logged in, devices loaded

? Choose device Bedside Light (Model: T1011, Code: E095B5767FF24402, IP Address: 10.10.20.39)
(AbstractDevice.connect) Connecting
(TcpSocket.connect) Connecting at 10.10.20.39
(AbstractDevice.new) TCP Socket connected
(AbstractDevice.connect) Connected to device Bedside Light (Model: T1011, Code: E095B5767FF24402, IP Address: 10.10.20.39)
(AbstractDevice.connect) Loading current device state
(LightBulb.loadCurrentState) Loading current device state
(LightBulb.getState) Loading current device state
(AbstractDevice.getSequence) Loading current sequence number
(AbstractDevice.sendPacketWithResponse) 1415801,E095B5767FF24402,0
(AbstractDevice.sendPacketWithResponse) Response received: {"type":"Buffer","data":[88,178,79,175,3,190,198,162,99,51,143,19,40,205,59,77]}
(AbstractDevice.sendPacketWithResponse) Response decrypted: {"type":"Buffer","data":[12,0,8,130,139,154,171,11,18,0,26,2,8,1,0,0]}
(AbstractDevice.sendPacketWithResponse) Deserializing response as T1012Packet
(AbstractDevice.getSequence) Current sequence number: 3043394946
(LightBulb.getState) Sending request to device
(AbstractDevice.sendPacketWithResponse) 3043394947,E095B5767FF24402,,,1
Socket closed - attempting restart
(AbstractDevice.new) TCP Socket connected
(TcpSocket.connect) Connecting at 10.10.20.39
(AbstractDevice.new) TCP Socket connected
(AbstractDevice.getSequence) Loading current sequence number
(AbstractDevice.sendPacketWithResponse) 292434,E095B5767FF24402,0
(AbstractDevice.sendPacketWithResponse) Response received: {"type":"Buffer","data":[5,141,18,220,128,27,44,210,79,34,191,117,247,179,225,94]}
(AbstractDevice.sendPacketWithResponse) Response decrypted: {"type":"Buffer","data":[12,0,8,234,144,214,170,11,18,0,26,2,8,1,0,0]}
(AbstractDevice.sendPacketWithResponse) Deserializing response as T1012Packet
(AbstractDevice.getSequence) Current sequence number: 3042281578
(AbstractDevice.sendPacketWithResponse) Response received: {"type":"Buffer","data":[5,141,18,220,128,27,44,210,79,34,191,117,247,179,225,94]}
(AbstractDevice.sendPacketWithResponse) Response decrypted: {"type":"Buffer","data":[12,0,8,234,144,214,170,11,18,0,26,2,8,1,0,0]}
(AbstractDevice.sendPacketWithResponse) Deserializing response as T1012Packet
(LightBulb.loadCurrentState) Parsing current state as white light bulb
Error connecting to device: TypeError: Cannot read property 'getPacket' of undefined
sebmos commented 5 years ago

OK, thanks for that update. Unfortunately, with that I'm out of ideas.

The problem seems to be that at some point, the sequence number, which always needs to be incremented by 1, gets higher than a 32-bit integer, but the light bulb socket connection doesn't allow 64-bit integer numbers, either. (The socket closing immediately after sending a message is sent is a symptom of the message being invalid.)

This appears to be a problem with the light bulb communications protocol, although I'm open to any other ideas, suggestions & pull requests.

rodalpho commented 5 years ago

Ahh. Well, if I can assist further in any way, please let me know!

gonenutsbrb commented 5 years ago

Coming from issue #5

Sorry about the duplicate, probably should have read through these.

Is there any way we can reset the sequence number to stay below the 32 bit limitation? A factory reset of the plug or a new Eufy account perhaps?

sebmos commented 5 years ago

Hey @gonenutsbrb,

Unfortunately, there's no solution quite yet. Only one of my devices shows this problem, and I want to keep that one "broken", so I can try to build a fix. I don't think a new Eufy account would work, but a factory reset could, if that's possible on those devices. If you could try that, that could be a useful workaround for now!

sebmos commented 5 years ago

A quick update on the situation: The app suffers from the same problem (i.e. the socket closes under the same circumstances), but has a built-in fallback solution by going through Eufy's server-side API, through which it can still communicate with the device directly. (This is how Eufy allows you to toggle devices when you're away from home.)

Not sure if Eufy plans to fix that problem. The only alternative solution would be to understand the Eufy API, which would probably not be trivial without access to the different devices.

fai150 commented 4 years ago

getting the same error, no fix yet?

[Homebridge] [10/1/2019, 7:58:45 PM] [eufy] Add Accessory: Lamp mom - 7A572964FD764FDC [Homebridge] [10/1/2019, 7:58:45 PM] [eufy] Add Accessory: Lamp dad - C1B8EC1F25E34CAB [Homebridge] [10/1/2019, 7:58:45 PM] [eufy] Error connecting to accessory: Error: Socket closed without sending response [Homebridge] at Timeout.<anonymous> (/home/hoobs/.hoobs/node_modules/node-eufy-api/lib/tcp-socket.js:153:48) [Homebridge] at ontimeout (timers.js:436:11) [Homebridge] at tryOnTimeout (timers.js:300:5) [Homebridge] at listOnTimeout (timers.js:263:5) [Homebridge] at Timer.processTimers (timers.js:223:10)

danielschwartz commented 4 years ago

Running into this issue myself as well. Any stable fix on the horizon?

nathanrawlings commented 4 years ago

For what it's worth, I have two T1202 and both were having this same problem. I created a new Eufy account and adopted them again, and plugged those credentials into my Homebridge config, and one worked while the other did not. I have verbose cli logs if they would be helpful.

nathanrawlings commented 4 years ago

@sebmos I just found a workaround for this issue. Do a device reset, but just hold down the button for a full 30 seconds before re-adopting it into your Eufy account.

In my previous comment a few minutes ago I mentioned that I got one of my devices working but not the other. I was thinking on your comment that the problem was related to the sequence number getting too high, and how that could be reset. I realized that with one of the plugs I held the power button for longer, and that might have done a deeper/factory reset rather than a simple account and SSID disassociation.

I'll bet that until this issue is fully solved, the deep reset might be necessary periodically.

gonenutsbrb commented 4 years ago

Holy cow I had forgotten about those. I ended up swapping them out later because of this issue. Good to know there’s at least a workaround if I see them again. Thanks for coming back and updating the thread! Stay safe!

From: nathanrawlings notifications@github.com Sent: Tuesday, May 12, 2020 6:22:53 PM To: sebmos/node-eufy-api node-eufy-api@noreply.github.com Cc: gonenutsbrb gonenutsbrb@gmail.com; Mention mention@noreply.github.com Subject: Re: [sebmos/node-eufy-api] Devices added then immediately removed (#2)

@sebmoshttps://github.com/sebmos I just found a workaround for this issue. Do a device reset, but just hold down the button for a full 30 seconds before re-adopting it into your Eufy account.

In my previous comment a few minutes ago I mentioned that I got one of my devices working but not the other. I was thinking on your comment that the problem was related to the sequence number getting too high, and how that could be reset. I realized that with one of the plugs I held the power button for longer, and that might have done a deeper/factory reset rather than a simple account and SSID disassociation.

I'll bet that until this issue is fully solved, the deep reset might be necessary periodically.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/sebmos/node-eufy-api/issues/2#issuecomment-627688406, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIK7LVJAXFNE4KBLGSEDTWDRRHY63ANCNFSM4GU5J5OQ.

tkuebler commented 4 years ago

OK. So, this appears to be related to the issue linked above, google/python-lakeside#11. It happens, because the protobuf file taken from the python-lakeside library specifies the "sequence number" to be of type int32, and the value it's trying to set for your device is higher than that.

I'm not sure if this int32 classification is intentional or not - to verify, I've changed it to int64 on a branch. If that works for you, I can merge that change into the main branch.

To test this version, please run the following set of commands:

git checkout --track origin/sequence-number-bug
npm install
npm run build:clean
npm run build
npm run cli:verbose

In the future, you can switch between the master and the bug-branch using git checkout master and git checkout sequence-number-bug.

This fixed the same problem for me. T1011. Unfortunately I'm using homebridge and don't want to futz with my homebridge server npm modules to get one bulb working... Any ideas?

sebmos commented 4 years ago

@tkuebler This didn't actually end up fixing the problem for me - I'm glad it did for you!

ahmedbataweel commented 3 years ago

i have eufy bulb t1012 and when i config it its was a problem

Error connecting to accessory: Error: Socket closed without sending response at Timeout. (C:\Users\afnan\AppData\Roaming\npm\node_modules\homebridge-eufy\node_modules\node-eufy-api\lib\tcp-socket.js:153:48) at listOnTimeout (internal/timers.js:549:17) at processTimers (internal/timers.js:492:7)

so how to fix it @sebmos

sebmos commented 3 years ago

@ahmedbataweel - The only solution I'm aware of at this point is the one mentioned by @tkuebler above, although it doesn't solve the problem for my bulb. If that doesn't work, you're unfortunately out of luck for now - unless you find a solution somewhere else.

ahmedbataweel commented 3 years ago

ok so what i do with the bulb????

sebmos commented 3 years ago

You can still control it with the Eufy app - just not with Homebridge.

BTPankow commented 3 years ago

I was experiencing this as well with the cli (as well as the Homebridge application). It turns out that the light getState packet construction has a typo, which caused the message to be rejected and the socket to be closed.

Instead of bulbInfo, this should be bulbinfo here: https://github.com/sebmos/node-eufy-api/blob/main/src/device-light-bulb.ts#L24 Based on this .proto definition here: https://github.com/sebmos/node-eufy-api/blob/main/src/lakeside.proto#L38

After making that change, things seemed to work as expected with the cli.

I can make a pull request if you'd like, but it is a pretty small fix.

On a similar note, I was seeing unexpected behavior with the sequence number returned in getSequence(), where the currentSequence was treated as a string and the + 1 appended a 1 character to the string: https://github.com/sebmos/node-eufy-api/blob/main/src/device-base.ts#L316 This didn't seem to have any visible consequences, but would also probably be worth checking and fixing if you also observe this behavior. parseInt seemed to work as expected (though I'm not sure why as number didn't, though I didn't look into it too much).

sebmos commented 3 years ago

@BTPankow Thanks, good catch - will update that. (I don't have a light bulb myself, so it's tricky to debug that!)

For the sequence change: This is odd - the sequence shouldn't be a string, I've always seen it as a number, but I'll add string parsing regardless - can't hurt. Oh, and as number is purely a TypeScript concept, and used to tell TypeScript explicitly what the data type is, but doesn't actually change it. This is necessary in this case, as the protobuf object isn't typed, so for TypeScript, everything is an any type.

sebmos commented 3 years ago

I've applied @BTPankow's change suggestions and released them as version 0.3.3 (both node-eufy-api & homebridge-eufy). I can't test either of them, so would appreciate feedback for any owners of Eufy light bulbs.

ahmedbataweel commented 3 years ago

thanks for that but can u contact me in discord RIK#6464

On Tue, Dec 15, 2020 at 12:32 AM Sebastian notifications@github.com wrote:

I've applied @BTPankow https://github.com/BTPankow's change suggestions and released them as version 0.3.3 (both node-eufy-api & homebridge-eufy). I can't test either of them, so would appreciate feedback for any owners of Eufy light bulbs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sebmos/node-eufy-api/issues/2#issuecomment-744723248, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARCDE53FKEGZI635OY2GFFDSUZ75VANCNFSM4GU5J5OQ .

Don-van-Houts commented 3 years ago

Good morning, Can you expand to me how I can integrate “Eufy video doorbell 2K” to my homebridge? I had it working, but for some reason it’s not working anymore. And I have the bridge “Homebridge Eufy” and “Homebridge security” installed.

Thx. Met vriendelijke groet,

Don van Houts

Op 14 dec. 2020 om 23:56 heeft ahmedbataweel notifications@github.com het volgende geschreven:



thanks for that but can u contact me in discord RIK#6464

On Tue, Dec 15, 2020 at 12:32 AM Sebastian notifications@github.com wrote:

I've applied @BTPankow https://github.com/BTPankow's change suggestions and released them as version 0.3.3 (both node-eufy-api & homebridge-eufy). I can't test either of them, so would appreciate feedback for any owners of Eufy light bulbs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sebmos/node-eufy-api/issues/2#issuecomment-744723248, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARCDE53FKEGZI635OY2GFFDSUZ75VANCNFSM4GU5J5OQ .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/sebmos/node-eufy-api/issues/2#issuecomment-744763250, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQQ3P75OPFXO4QDBP4OOULLSU2J2FANCNFSM4GU5J5OQ.

sebmos commented 3 years ago

@Don-van-Houts - This would be something you'd have to check with the "homebridge security" documentation, I assume. homebridge-eufy doesn't support video doorbell products.

jlclarkrx commented 3 years ago

Thank you for your work on this. The latest updates seems to be getting us closer with the bulbs in homebridge. I have three T1013 bulbs and they are no longer being removed and are shown in homekit but constantly get a "No Response". Below are the errors on the log:

12/15/2020, 7:39:33 AM [eufy] Error loading power state on device: Jarrods Bulb - Error: Socket closed without sending response at Timeout. (/home/hoobs/.hoobs/node_modules/node-eufy-api/lib/tcp-socket.js:153:48) at listOnTimeout (internal/timers.js:531:17) at processTimers (internal/timers.js:475:7) 12/15/2020, 7:39:33 AM [eufy] Error getting brightness on device: Jarrods Bulb - Error: Socket closed without sending response at Timeout. (/home/hoobs/.hoobs/node_modules/node-eufy-api/lib/tcp-socket.js:153:48) at listOnTimeout (internal/timers.js:531:17) at processTimers (internal/timers.js:475:7) 12/15/2020, 7:39:33 AM [eufy] Error getting temperature on device: Jarrods Bulb - Error: Socket closed without sending response at Timeout. (/home/hoobs/.hoobs/node_modules/node-eufy-api/lib/tcp-socket.js:153:48) at listOnTimeout (internal/timers.js:531:17) at processTimers (internal/timers.js:475:7) 12/15/2020, 7:39:33 AM [eufy] Error getting color hue on device: Jarrods Bulb - Error: Socket closed without sending response at Timeout. (/home/hoobs/.hoobs/node_modules/node-eufy-api/lib/tcp-socket.js:153:48) at listOnTimeout (internal/timers.js:531:17) at processTimers (internal/timers.js:475:7) 12/15/2020, 7:39:33 AM [eufy] Error getting color saturation on device: Jarrods Bulb - Error: Socket closed without sending response at Timeout. (/home/hoobs/.hoobs/node_modules/node-eufy-api/lib/tcp-socket.js:153:48) at listOnTimeout (internal/timers.js:531:17) at processTimers (internal/timers.js:475:7)

sebmos commented 3 years ago

@jlclarkrx Can you start the node-eufy-api CLI in the verbose mode?

You'll have to check out this repo, then run npm run cli:verbose

BTPankow commented 3 years ago

@sebmos Thanks for making the fix. I will say that I mostly tested with the cli, which worked for me. I might have seen the same behavior as @jlclarkrx with homebridge-eufy, but I didn't have much time to test it. I only tested with T1012 bulbs, so that could also be a difference.

I don't have access to any bulbs right now, but I might be able to play around with it later this month to see what what's going on.

BTPankow commented 3 years ago

Based on a quick look, it might be that subsequent calls to getState() may still cause problems. From what I can tell, it looks like cli.js only calls that once when it connects to a bulb, which might be the difference. I don't know what the protocol should be, but there might still be something in the getState() packet that needs to be present.

jgadzhiev commented 2 years ago

26.07.2021 Hi All,

I am a newcomer to Homebridge, Hoobs etc. topic. However, with:

The Hoobs Version 4.0.92 The Node Version 14.17.2 The Homebridge Version 1.3.4 The Eufy Hoobs Plugin Version 0.3.5 The Eufy Device is T1011 Lumos Smart Bulb - White

the problem with the Eufy Smart Bulb still persists. The device works when managing it from Hoobs GUI. But, once I open Apple Home I receive:

"26/07/2021, 19:08:13HomeeufyError loading power state on device: Dining Room Light - Error: Socket closed without sending response at Timeout. (/var/lib/hoobs/home/node_modules/node-eufy-api/lib/tcp-socket.js:153:48) at listOnTimeout (internal/timers.js:557:17) at processTimers (internal/timers.js:500:7)

I could sound like a deletant, however, the Google Home Integration works perfectly fine and without a single bug since 2 years when I have applied Google Home App Integration to Eufy (which's supported)

ibmaster commented 1 year ago

Confirming doing a device hard reset and re-add of device to your eufy account still a viable (though painful) workaround to recover the Homebridge operation of eufy's wall switch.