search

konsumer / tplink-lightbulb

Control TP-Link smart lightbulbs from nodejs
MIT License
190 stars 32 forks source link

TypeError: Cannot read property 'length' of undefined #18

Closed superhac closed 6 years ago

superhac commented 6 years ago

Looks like theres an issue with theversion of json-colorizer your using.

$ tplight on 192.168.5.13 TypeError: Cannot read property 'length' of undefined at Object.getTokens (/usr/local/lib/node_modules/tplink-lightbulb/node_modules/json-colorizer/src/lib/lexer.js:34:18) at colorizeJson (/usr/local/lib/node_modules/tplink-lightbulb/node_modules/json-colorizer/src/lib/index.js:5:35) at /usr/local/lib/node_modules/tplink-lightbulb/build/cli.js:25:50 at /usr/local/lib/node_modules/tplink-lightbulb/build/cli.js:48:26 at at process._tickCallback (internal/process/next_tick.js:188:7)

Thanks,

konsumer commented 6 years ago

I will take a look. It could be that I need a guard around undefined return values (which is not valid JSON.) What model lightbulb are you using? I can't reproduce your issue locally with an LB120 or LB130.

superhac commented 6 years ago

Actually , I'm not using the light bulbs. I have the HS200 switches. LOL. I really wasn't paying attention when I installed your code. But now I clearly see its for just for the light bulbs. ;) So its on me!

Since thats the case you can close the issue. I can dig into your code and see about getting it to work on switches. It must be getting some returned data its not expecting.

Interestingly the "scan" and "details" command work.

Thanks for help!

konsumer commented 6 years ago

That's a good sign! Yeh, it's not tested with any plugs, and I think it has issues (#17) but I'd like to support them if possible, and I got one (HS105) for xmas, so we'll see. My plan of attack (when I have time to set it up) is to use the instructions to setup a pi as a fake wifi AP, then monitor traffic and see what's different about the messages (I bet it's the same whack encryption, just different JSON format for messages.) After that, it should just be a matter of a little bit of switching based on target device.

At some point, I'd also like to document exactly what flags/commands work with different devices (for example color commands only work on LB130.)

superhac commented 6 years ago

Great to hear. I also have a HS100, which i think is the predecessor to the HS105. I haven't had time yet to get around the code, but I'll let you know if I get around to it. You'll probably beat me now that you have one! ;) I think the all the switches are the same regardless of their model, at least so far.

konsumer commented 6 years ago

Yeh, tp-link seems to keep devices pretty similar (I think this whole protocol came from routers, originally!) so it should be fairly easy to work with. If I have time tonight, I'll set it up. Maybe after I get it put together you can do some testing. It'd be awesome to have a verified list of models/commands that work.

konsumer commented 6 years ago

I added a support-matrix to README. At some point, I should make a kasa-workalike as a react-native/electron app, to really show off the library, but first I need to support all of these.

konsumer commented 6 years ago

Oh wow! Looks like tplink-smarthome-api has added a lot to the API since I last checked. Not sure if there is a point to an alternative implementation any more, but I do like my simpler interface. For now, I'd recommend using their lib, but I may add more devices if I have time.

konsumer commented 6 years ago

Ok! I added support for devices that use a relay (like yours.) Test it out with tplight on 192.168.5.13.

konsumer commented 6 years ago

I also updated the support-matrix table, but it could use testing, so please verify all the X'd commands work on your device.

superhac commented 6 years ago

Wow. That was quick. I tested both the HS100 and HS200's this morning and they both work now! Great job on this. From a testing perspective I ran what I think are the four relevant commands: details, on, off, scan. All worked flawlessly. Nice job on the matrix also!

Thanks for the link on the alternative node implementation of tp-link api. Really for me the only element that is missing is from your implementation is scheduling. But in reality you can do scheduling two ways, either from a client with a timer using the on/off or loading the schedule in the device itself.

The reason I was actively seeking out a node implementation of this is because recently I just installed some new networking equipment and finally now have all this Home Automation stuff isolated to their own VLAN. When you do this it causes some interesting problems. Mainly, all local control breaks in their apps because unless your connected to the same subnet, they all use broadcasting to detect devices, which doesn't work when your app is on another network. So I needed some alternative method to control my devices when there on another network that different then the one I'm running the Kasa app on. The easy solution is using their cloud implementation, but I don't want that.

My first idea was to modify the Kasa APK and change the discovery from a Broadcast (255.255.255.255) to a Directed Broadcast (X.X.X.255). So I coded up a test to see if the TP-Link devices would respond to a Directed Broadcast and sure enough it worked. All my devices would respond to a Directed Broadcast from an IP on different network. But I couldn't use this method since the networking equipment (Ubiquiti) I have doesn't support the forwarding of Directed Broadcasts! :( Hopefully they will add that feature in the future. You should add an additional option to the "scan" command support a Directed Broadcast.

After that method failed for me, I ended up here. ;) My idea was to use your library to code a crude web front-end (I'm not a front-end guy) that I could use to control my devices. So if your plaining to do your react front-end I'm all for it!

Thanks again for adding the switch support!

superhac commented 6 years ago

I just tested the "raw" command for the HS100 and the HS200 and that works also.

I don't know what the cloud command does, but that errors out:

tplight cloud 192.168.5.12 TypeError: Cannot read property 'length' of undefined at Object.getTokens (/usr/local/lib/node_modules/tplink-lightbulb/node_modules/json-colorizer/src/lib/lexer.js:34:18) at colorizeJson (/usr/local/lib/node_modules/tplink-lightbulb/node_modules/json-colorizer/src/lib/index.js:5:35) at /usr/local/lib/node_modules/tplink-lightbulb/build/cli.js:30:50 at /usr/local/lib/node_modules/tplink-lightbulb/build/cli.js:92:12 at at process._tickCallback (internal/process/next_tick.js:188:7)

konsumer commented 6 years ago

All worked flawlessly. Nice job on the matrix also!

Nice! These are the basic commands I expected to work, so that's good to hear they do actually work.

Really for me the only element that is missing is from your implementation is scheduling. But in reality you can do scheduling two ways, either from a client with a timer using the on/off or loading the schedule in the device itself.

Yeh, agreed. I'd like to add scheduling at some point, but for the project I was working on when I started this, I didn't need it, and I figured, like you, I could just use external scheduling if I needed it, so I saved it till last.

My idea was to use your library to code a crude web front-end (I'm not a front-end guy) that I could use to control my devices. So if your plaining to do your react front-end I'm all for it!

Yeh, I would like to do this. I think I need to get scheduling and new device discovery worked out (so it can be a full replacement for Kasa app.) In the meantime, I added a broadcast IP param to scan() and scan, (with a default of the original) so you can scan on a different subnet:

tplight scan -b 192.168.86.255

I don't know what the cloud command does, but that errors out

Yeh, I think that might be specific to the lightbulbs, but I will play around with it more.

I'm going to close the issue for now, but feel free to open it again, if you have issues with plugs.

konsumer commented 6 years ago

As a sidenote, I'd be happy to work on some components right now (before I work out scheduling) to help you with your web-panel. I think there would be some overlap with a desktop react-client (like maybe yours could use socket.io to sync state & send commands, but basically work the same.)

I'm thinking there are a few components that would be useful to us both, right away:

Since you don't have bulbs, these will be less useful, but I'll probly make them, too:

konsumer commented 6 years ago

I started working on web-based interface, here.

You could use it, as it is, to control your plugs. I'll add more features when I have time, but it should be a good start.

superhac commented 6 years ago

Thats great. That would work for me. I would just render any of the device properties (e.g. things you can change or configure) as specific runtime renderable attributes that can be changed. Then if new devices are added in the future they just automatically rendered with any of their specific configurable attributes.

I also tested your new "Directed Broadcast" option is works great!

superhac commented 6 years ago

I started working on web-based interface, here.

You could use it, as it is, to control your plugs. I'll add more features when I have time, but it should be a good start.

Nice job on the web-interface. Looks really good. Can't wait to try it out!