Smartlife Tuya Aoycocr

Hi All,
I'm a Noob here, so please bear with my questions....

I've just followed an instruction to do a tuya-convert on my Aoycocr plug.
I've flashed it successfully to a tasmota.bin.
But I believe I will need to install the driver first before hubitat can detect it.
Can I please get some help on this?
I'm not sure if I should flash the plug with another different firmware that hub will then able to detect by default?

Cheers for your help.

Your right you will need a driver to use it. Have a look here Hubitat/drivers/expanded at master · markus-li/Hubitat · GitHub and i'd just give the Generic Tasmota Plug driver a go and see if it works. There is also a dedicated thread where @Marcus helps out alot.

2 Likes

Thanks. Do you have the link to the thread? I've added the driver, but not sure what i need to do on the hue bridge section.

I would recommend using the firmware and driver combo released by @ericm.

You would, would you? May I ask why that one instead of the more recent version?

Before posting my response, I'd like to ask 2 questions myself....

First....do you really want an answer? Because I will gladly give you one. You will most likely find it rude but I'm more than willing to answer your question.

Second, do you care? If so, then why didn't you listen when I voiced my concerns on the thread where you released your drivers? And if not, then why bother even asking?

Please do give your “rude answer”, I actually do care, if it can be used constructively I’m interested.

I've stated all of this on the thread where you released your drivers.....

Since your firmware is based on his, I can only assume that you agree that his is a very excellent solution to the problem of local reporting of status changes on the device. And since that is the major difference between stock Tasmota and his/your firmware, then it all comes down to drivers.

I feel your architecture is unnecessarily complicated. You have too many drivers that are unnecessarily specific to the devices they control. Your drivers are also created in a way that requires users to "figure out" which ones they need or spend hours loading all 52 of them into Hubitat. That is unnecessarily complicated. This could be achieved in a much simpler, easy to understand, easier to maintain fashion. When something is very complicated, it is easier for it to fail.

You also don't listen to those folks that either have been here longer that you or are the ones who actually designed the system in the first place.

In addition, you've been here 51 days. IMHO, that is not long enough to demonstrate a long term commitment to maintaining an integration of this magnitude. If you were to just give up and leave tomorrow, what would that mean to folks using your drivers? That means they would be left out in the cold. No assistance. I mean, look at the main thread of your implementation? There are dead-links and it is extremely difficult to follow. The necessary work to maintaining an integration of this magnitude is not being done so I don't feel that it is right to recommend using it. I mean, you had to be told just recently, that everything that switches on and off should have the switch capability. As someone developing and releasing for this platform, that is not something you shouldn't have learned weeks after releasing this package. It makes me wonder what else have you overlooked.

I've used Eric's firmware and drivers for years. I know his level of coding skill because he has demonstrated a consistent level of excellence. He's not perfect...no one is. But I know when I use something of his he stands behind it and takes the time to listen to those that have concerns and input. As stated earlier, I don't know you, so I'm not going to recommend using your drivers.

But for the record, before you asked, I didn't say why anyone should choose one over the other, I merely stated my recommendation. And if you want to integrate a Tasmota device that simply switches on/off, like most of them do, then Eric's implementation is more than you would ever need.

Thank you for the input, it is late here now, so I’ll write a full reply tomorrow.
I do understand where your comments come from, and will address them tomorrow.

My complete reply:

Partially, yes, I do appreciate you taking the time to do it again.

It is a very excellent way of doing it, it ties into and uses the same message as what would be published to MQTT. There is a bit of adapting it to new firmware releases, but it is nothing major to maintain now that it has been changed to the new structure used in Tasmota 7.x and 8.x. I would never have involved myself in the firmware part if it weren't for the fact I saw a need for features in newer versions of Tasmota and @ericm didn't have the time.

I agree that it may have become complicated, I do intend to sort this out, but it does have its reasons to begin with. What I intend to do is to clearly separate the drivers which have FUNCTIONAL differences, there's quite a few of those. If capabilities/commands could be dynamic it could be made to be even fewer, but that is not the case. As for making it easier to choose, that is a documentation thing as well, I'm getting help with that from @jchurch and @maffpt and it will be made clear.
To clarify, a couple of things I do want to do is to possibly move the specific device settings into a drop-down selection in the driver and companion app, consolidate more of the non-device specific drivers into fewer ones, but here I'd need input and to discuss this with the community.
In terms of failing due to complexity, code-wise it won't (at least not due to many drivers) because it is not complex to maintain, it is automated. Failing due to complexity for the user to choose, that it has in some ways, this requires a re-structure and additional documentation.

I do listen, and I ask for advice, I also ask for things I want, though I have not done much of that. So where this comes from I don't really understand.

51 days here, sure, I do understand that hesitation, and it is up to each and everyone to make that choice. I know I have no intention of not committing long-term, but life can happen. The only way to get any open source project to TRUE long-term viability and stability is to have more than 1 developer to begin with. In time I do hope to get there.
As for a difficult to follow thread, ok, I'm open for specifics here, attention to detail is important, but I prefer to put that effort into the actual code, if someone else helps with other parts, then it becomes more likely to be well documented.

This is a much more complex issue than you seem to think, maybe having been here for a long time you feel it is obvious that Switch needs to be there as a capability, but not even all developers who have been here for a long time do it this way, nor is it 100% clear. I had assumed I needed it, and had put it in the drivers, but the exact and correct setup of capabilities is complicated by how for example integrations with Alexa function. This did need a recent and clear statement to be sorted, now it is. And for what else I've overlooked, probably something important that is "obvious" to someone who has been here for a long time. With that being said, code-wise my drivers are solid, best-practice wise, I might still not know all best practices. But since you seem to know them, if you want to truly help-out, maybe create a post going through and listing all best-practices/requirements and linking to the information establishing them? I'm certain I wouldn't be the only one appreciating such a thing.

Noted, to each his own needs and thoughts. I'm happy some people do like what I write, if you're not one of them, that is just how it is. I do like constructive input, however.

I have no issue you stating any of this, it's good for people to read and form their own opinion about. And as for the simply on/off integration, I'd say yes, his implementation will do what is needed, and as long as I don't have an app which makes installation easier than his driver, there is no reason to change unless there's some need for features in more recent version of Tasmota.
I would however want to say one thing, there ARE reasons to run a more recent version of Tasmota if you're installing a NEW device. Upgrading devices that work and are already fully functional is something for those that like this type of thing, but that goes for IoT in general (except for security patches) in my opinion...

I have no idea if this helps anyone, but I do hope it gives some perspective and makes it easier to choose what is right for them. What I didn't want was to leave this without discussing it. There are reasons for everything, and most things can change.

1 Like

@markus ignore ryan. He has issues with everyone who doesn't think like him. Put him on ignore like I did. Eventually @bravenel will get tired of him and ban him for a few weeks as usual.

2 Likes

@Ryan780 instead of trolling why don't you offer support to your fellow community? Your clearly an intelligent person albeit wasted by always having the need to point out issues with people's code or whatever. As we say in Australia "pull your head in mate!"

EDIT: I respect @markus a lot he's new (newer than me) to the community and has taken on a lot e.g Tasmota support that is lacking and broad. I am personally trying to help him along but I cannot do it by myself please help.

2 Likes

Or out if that's the case.......

1 Like

I do see this, at the same time, I don’t like ignoring people, I’ll give reasoning a chance. I do hope I don’t make a mistake not taking your advice, time will tell... I take any opportunity to receive constructive criticism, so far this thread is civilised. :slight_smile:

I had no idea what that meant. Come to find out there is an entire site for Outback speak. :grinning:
https://outbackdictionary.com/pull-your-head-in/

3 Likes

I would like to direct your attention to this post....

I asked point blank if he wanted my honest input. That is what I provided. I didn't put this up without first being asked to give it. I merely offered my recommendation on what I thought was the best solution to the OP's problem. Nowhere did I mention @markus's code until he asked me to provide that feedback. If you don't want me to say what I think, don't ask me what I think. Fair enough?

BAHAHA i had no idea this site existed that's gold! Thanks mate!

EDIT: what I should have said is "pull your head in you flaming galah!"

2 Likes

We’ll have to work hard on your predictions not coming true then :stuck_out_tongue:

1 Like

Only if you flag them. :smiley: I was asked for my opinion. If you don't like that, blame @markus, not me.

1 Like

No worries, blame me this time :slight_smile: I did ask in the hope something constructive comes out of this, if it doesn’t I guess I was wrong

@Ryan780 can you help us out with the Wiki? @markus and I would love to make this as simple as possible for other's. We would really appreciate the support.