Devices added then immediately removed #2

rodalpho · 2019-02-07T13:47:40Z

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

The text was updated successfully, but these errors were encountered:

sebmos · 2019-02-07T20:28:08Z

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 · 2019-02-08T00:47:11Z

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 · 2019-02-08T04:00:58Z

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 [email protected]: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 · 2019-02-08T04:30:20Z

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 · 2019-02-08T04:51:45Z

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 · 2019-02-08T04:58:40Z

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

sebmos · 2019-02-08T05:04:32Z

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 · 2019-02-08T05:20:17Z

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 · 2019-02-08T05:55:43Z

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

rodalpho · 2019-02-08T14:17:06Z

Right, did not fix it.

sebmos · 2019-02-08T21:25:10Z

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 · 2019-02-09T00:35:03Z

No problem, appreciate it!

sebmos · 2019-02-11T22:23:10Z

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 [email protected]

rodalpho · 2019-02-12T02:00:19Z

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


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

> [email protected] 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 · 2019-02-13T23:01:52Z

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: google/python-lakeside#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 · 2019-02-14T00:43:31Z

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

sebmos · 2019-02-14T20:21:46Z

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.

rodalpho · 2019-02-15T01:12:26Z

Still get an error, output is below.

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

> [email protected] 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 · 2019-02-15T20:42:57Z

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 · 2019-02-16T01:10:17Z

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

gonenutsbrb · 2019-03-12T00:53:32Z

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 · 2019-03-12T08:27:44Z

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 · 2019-03-24T09:10:46Z

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 · 2019-10-02T01:04:31Z

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 · 2019-12-11T17:27:29Z

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

nathanrawlings · 2020-05-13T00:57:36Z

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 · 2020-05-13T01:22:41Z

@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 · 2020-05-13T10:20:52Z

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 <[email protected]> Sent: Tuesday, May 12, 2020 6:22:53 PM To: sebmos/node-eufy-api <[email protected]> Cc: gonenutsbrb <[email protected]>; Mention <[email protected]> Subject: Re: [sebmos/node-eufy-api] Devices added then immediately removed (#2) @sebmos<https://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 GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AIK7LVJAXFNE4KBLGSEDTWDRRHY63ANCNFSM4GU5J5OQ>.

tkuebler · 2020-06-22T20:51:50Z

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 · 2020-06-22T22:10:53Z

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

ahmedbataweel · 2020-09-20T21:01:34Z

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 · 2020-09-21T09:58:53Z

@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 · 2020-09-21T10:10:15Z

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

sebmos · 2020-09-21T10:21:25Z

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

BTPankow · 2020-12-01T01:36:24Z

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 · 2020-12-13T23:31:04Z

@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 · 2020-12-14T21:31:55Z

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 · 2020-12-14T22:56:19Z

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

…

On Tue, Dec 15, 2020 at 12:32 AM Sebastian ***@***.***> 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 <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARCDE53FKEGZI635OY2GFFDSUZ75VANCNFSM4GU5J5OQ> .

Don-van-Houts · 2020-12-15T06:21:37Z

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 <[email protected]> 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 ***@***.***> 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 <#2 (comment)>, 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 GitHub<#2 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AQQ3P75OPFXO4QDBP4OOULLSU2J2FANCNFSM4GU5J5OQ>.

sebmos · 2020-12-15T09:04:57Z

@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 · 2020-12-15T13:44:21Z

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 · 2020-12-15T14:55:22Z

@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 · 2020-12-18T01:12:10Z

@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 · 2020-12-18T01:32:04Z

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 · 2021-07-26T17:26:50Z

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 · 2022-12-08T17:45:21Z

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.

sebmos mentioned this issue Mar 8, 2019

Eufy Plug Mini T1202 #5

Open

sebmos mentioned this issue May 1, 2019

Accessories No Longer Appear sebmos/homebridge-eufy#4

Open

digitalec mentioned this issue Jun 15, 2019

Socket closed without sending response (timeout.js:153) #6

Closed

This was referenced Jan 23, 2020

CORS issue at calling loadDevices #10

Open

Homebridge Not Finding Bulbs sebmos/homebridge-eufy#7

Open

sebmos mentioned this issue Feb 25, 2020

Device T1012 not working #11

Open

sebmos mentioned this issue Sep 21, 2020

T1012 #14

Closed

sebmos mentioned this issue May 9, 2021

Eufy / Homebridge error #17

Open

Devices added then immediately removed #2

Devices added then immediately removed #2

Comments

rodalpho commented Feb 7, 2019 • edited Loading

sebmos commented Feb 7, 2019

rodalpho commented Feb 8, 2019 • edited Loading

sebmos commented Feb 8, 2019

rodalpho commented Feb 8, 2019

sebmos commented Feb 8, 2019

rodalpho commented Feb 8, 2019

sebmos commented Feb 8, 2019

rodalpho commented Feb 8, 2019 • edited Loading

sebmos commented Feb 8, 2019

rodalpho commented Feb 8, 2019

sebmos commented Feb 8, 2019

rodalpho commented Feb 9, 2019

sebmos commented Feb 11, 2019

rodalpho commented Feb 12, 2019

sebmos commented Feb 13, 2019 • edited Loading

rodalpho commented Feb 14, 2019

sebmos commented Feb 14, 2019

rodalpho commented Feb 15, 2019

sebmos commented Feb 15, 2019

rodalpho commented Feb 16, 2019

gonenutsbrb commented Mar 12, 2019

sebmos commented Mar 12, 2019

sebmos commented Mar 24, 2019

fai150 commented Oct 2, 2019

danielschwartz commented Dec 11, 2019

nathanrawlings commented May 13, 2020

nathanrawlings commented May 13, 2020

gonenutsbrb commented May 13, 2020 via email

tkuebler commented Jun 22, 2020

sebmos commented Jun 22, 2020

ahmedbataweel commented Sep 20, 2020

sebmos commented Sep 21, 2020

ahmedbataweel commented Sep 21, 2020

sebmos commented Sep 21, 2020

BTPankow commented Dec 1, 2020

sebmos commented Dec 13, 2020

sebmos commented Dec 14, 2020

ahmedbataweel commented Dec 14, 2020 via email

Don-van-Houts commented Dec 15, 2020 via email

sebmos commented Dec 15, 2020

jlclarkrx commented Dec 15, 2020

sebmos commented Dec 15, 2020

BTPankow commented Dec 18, 2020

BTPankow commented Dec 18, 2020

jgadzhiev commented Jul 26, 2021

ibmaster commented Dec 8, 2022

rodalpho commented Feb 7, 2019 •

edited

Loading

rodalpho commented Feb 8, 2019 •

edited

Loading

rodalpho commented Feb 8, 2019 •

edited

Loading

sebmos commented Feb 13, 2019 •

edited

Loading