[BETA]TuyaHubitat - (jinvoo, smart life, tuya smart - switches only)


#41

Anybody get any bulbs working?
I've got two RGB that I would like to add.
Home Assistant has it on lock.

Thanks!


#42

I don’t know... but I just picked up 5 of these for my last bedroom to sort out - the existing light fittings are B15, which really limits room to manoeuvre.

I’m in work for the next few days... but if nobody else has already got at it... i’ll have a bash at extending the existing stuff to do RGB bulbs.

— Jules


#43

Any experience with docker?
It would be lovely if the necessary middleman server where docker-tized.
Thanks for any effort you add.


#44

It's probably heretical, but my general experience with docker is that it's a good way to add another layer of abstraction and confusion between an application and the platform it's running on, and I slightly cynically think that lots of people containerise their applications to avoid having to properly document install mechanisms and pre-requisites :wink:

On a more rational level, I entirely see the benefit if I'm going to be personally responsible for several thousand instances of something. If I want to produce ONE, though, i struggle to see the benefits.

But... I'm an old curmudgeon. I still don't see why proper machines for doing work should have GUI's on them, and that text editors with cursor keys are for the weak.

:wink:

-- Jules


#45

My biggest reason for containers is I like to keep host operating systems as clean as possible.
Buying 10 Raspberry Pi's for my various needs is not feasible when one can run those 10 different applications just fine.
They don't all play nice with each other, one has this dependency which breaks that other thing you had working for months.

In my line of work we don't ship anything out our doors that isn't virtualized if it's running on a server.
Luckily for me I've gotten on this elevator at the ground floor professionally so it carries over to my hobbies well.
It's hard to argue with how darn easy docker makes it,
Issue a command, modify a file with your paramters, restart it and you're up and running.

Hass.io is built around it and exposes the pertinent config file right in the WebUI.
It makes life so much easier once you've embraced it.
joinus....joinus... :zombie:


#46

Hehe. I don't necessarily disagree - I'd not stick any of this lot on a Pi, to be honest. They're great fun things... but they have literally zero redundant components.

A VM on an environment with (at the very least) decently resilient storage is the way forward, even for home usage, to my mind.

And in terms of the dependencies... I hear you entirely, although this is largely a result of some pretty shonky development decisions to my mind. Node is a really prime offender for this - the fact you need npm to even begin to play in the space is a policy of despair - just see the chaos caused every time somebody unpublishes or otherwise breaks, or (heaven forbid, somebody actually compromises) one of the low level packages everything relies on - I honestly don't know how you could ever produce a product that relies on those sorts of things without having to security audit a few thousand 3rd party packages.

And the other major offender is python - for much the same reasons - vast over-reliance on 3rd party packages of dubious provenance.

Anyway... I digress. I'll try to get the lights running... if I succeed, maybe you'd like to take care of it's packaging :wink:

-- Jules


#47

Haha I tried to make my first container a little while ago.
Not as straight forward as creating a virtual machine.
At least to me, perhaps if I were paid to do it I'd figure it out faster as life goes.
:wink:

I tried to create a container for the Google Assistant Relay, but that's not necessary anymore.
And to my earlier point, now I've got that whole mess installed on my Pi and who knows how to cleanly uninstall it all.
With a container I just blow away the container.


#48

Just to chime in a bit. I one time I was very interested in docker. I figured out how to use it, got HousePanel running in a container. But to me it felt like extra work to maintain and very difficult to interact with and change.
I found I would rather take the time to figure out what dependencies are in play and get my system setup to handle them.

Beautiful thing about the pi is it takes only a few minutes to revert if you think you messed something good. Always back up before you and play, and restoring is a piece of cake.


#49

Portainer makes running docker on a Pi so easy.


#50

I am guessing this will be a bit of a challenge. I have not perused the tuyapi github in awhile, I know however they have made great leaps since I built this driver, and at the time bulb support was not built in. Some users and developed some libraries to make the bulbs work though. The node server and driver will not even work with the latest version of tuyapi.

I think it would be great if someone picked this up and ran with it. I only have a couple of these plugs, and what is here works well for me. So I have no hardware to even attempt with.


#51

Hehe. I'll give it a go.

My requirement isn't that strong - it's literally 5 bulbs in the second-least important spare bedroom in the house - we have to have 5 separate sets of house guests before there's any possibility of that room being occupied, but I like a project :wink:

-- Jules


#52

I'm very interested in your Tuya Hubitat drivers. I may be able to help with coding as well eventually. I have several RGB bulbs, an IR blaster, a Multi Switch, a single switch, motion sensor, door sensors and a siren. I'm needing help with the initial setup right now as I'm new to Hubitat.


#53

Hmmm. OK. Well... I've only got a few bulbs, but I'll take a look and see what I can get to work :wink:

To be honest, it looks like a pretty unattractive integration, in that it needs an external node.js environment, which is the sort of thing I'm trying to get away from, but hey... the bulbs were VERY cheap, and they were literally the only game in town for the light fittings that were there.

Best Regards,

Jules


#54

I don't see why this can not be coded into a Hubitat app or direct driver. I guess I am missing something there, I'll dig in further soon as well.


#55

Looking (briefly) at the node driver... yeah... It's not ENTIRELY obvious to me either why it's actually a total requirement.

The 'grab the IDs and keys by MitM attack' bit looks out of scope of it, but once you've grabbed the slightly horrible combo of device ID (which looks to be some sort of static magic plus MAC address), secret (which changes, apparently, per setup), and IP address of the bulb itself, then I haven't quite worked out what the secret sauce is that stops it being native.

Anyway... if I can produce a straightforward device driver that can do on/off/brightness/color for my bulbs via the existing node relay, then I'll maybe dig a bit deeper. Thus far, a little tinkering has got me devices that can report their health, and (probably) turn on and off. I say probably because my keyboard and the nearest light fitting that the bulb sits in are 3 floors away from each other :wink:

-- Jules


#56

I am 90% certain it can be done. Just have to figure out how to code the encryption/decryption in groovy.

Prior to recently, udp and websockets were not supported by hubitat. Now that they are I think the sky is the limit.


#57

Hmmm. Yeah. OK. tuyapi just calls a function to implement AES-ECB. I don't fancy writing an AES implementation in groovy itself - so I guess the question is whether there's any merit in asking nicely for ciphers to be in the Hubitat library, if they're not already. :wink:

-- Jules


#58

here is a link to groovy aes code... I was able to do the includes and save in Hubitat but it doesnt mean it loaded the includes.

Let me know what yall think.

http://groovyconsole.appspot.com/script/5172570915602432


#59

Hmmm. OK. Funky. It's worth a stab at least, then.

In the interim, I think I'll go for making a driver that requires the existing node helper server, on the basis that it'll be easier to troubleshoot that than deal with the test of the nuances at the same time. Then we can look at a native driver later if it turns out there's sufficient interest to get it done.

In that vein, I've got a (very rough) alpha that works well enough to turn individual lights on and off. While that's technically all I require of the implementation, I think I understand enough to extend it to at least do colour selection, so I'll give that a go during the week when I'm on looking-after-the-puppy duty rather than going in to work :wink:

-- Jules


#60

@cwwilson08 @JulesT Ok so the RGB Light Device Handler is really needed now... except it needs to use the sonoff connect App now thanks to the awesome work of SynAckFin GitHub - SynAckFin/TuyOTA: Flashing Tuya devices with Tasmota firmware. and https://github.com/codetheweb/tuyapi/issues/49
So I should have a Tuya bulb flashed tomorrow with the Sonoff firmware. Then hopefully @ericm will be interested in modifying the firmware to add rgbw light bulbs to his great list of firmware.

No more TuyAPI if this works....