node-eufy-api
node-eufy-api copied to clipboard
sebmos
Devices added then immediately removed
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 <
[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
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.
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/
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.)
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.
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?
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?
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.
Ok. I take it restarting (unplugging/replugging) the light bulb didn’t solve the problem, either?
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!
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]
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
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.)
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.
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
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.
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?
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!
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.
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)
Running into this issue myself as well. Any stable fix on the horizon?
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.
@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.
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)
@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.
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
int32classification is intentional or not - to verify, I've changed it toint64on 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:verboseIn the future, you can switch between the master and the bug-branch using
git checkout masterandgit 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?
@tkuebler This didn't actually end up fixing the problem for me - I'm glad it did for you!