BrettSheleski / SmartThingsPublic

36 stars 23 forks source link

Sonoff Dual R2 and 4Ch #23

Open Sym-Link opened 5 years ago

Sym-Link commented 5 years ago

Hey Brett,

Not really an issue but more of a comment. Just wanted to let you know that the Dual R2 works perfectly. As does the 4CH but you already had a thread about that one.

Thanks for all of your work on this,

Jeff

PS - Is there any plans to get the THs working where they would report back the temp/humidity to Smartthings?

BrettSheleski commented 5 years ago

I'll add you as a tester for the 4CH and Dual R2.

The way the device handler(s) are structured it should be pretty easy to add additional device handler(s) to report temperature and humidity. I just don't have the any such device to actually develop and test them.

If you feel up to doing so, please do and create a pull-request with the code. I'd gladly review and accept the pull request.

Sym-Link commented 5 years ago

Hey Brett,

I am not really a coder but I can usually figure things out and I can cut and paste. Yesterday I managed to use your parent handler and add temp and humidity to it. I also remove the attributes from the details that didn't seem to work. They always showed blank or null. Friendly name, group topic, ssid 1 and 2, and upTime were all removed. I also made the Temp and Humidity bigger on the details page and for the Smartthings favorites the icon shows the temp and changes color based on temp. Instead of refreshing, it takes you to the details page. You can see the changes I made in screenshots attached. Bella's Night Light Handle and Lagertha Handle are the THs I am using. screenshot_20181204-083036_smartthings screenshot_20181204-083053_smartthings

The only thing is I haven't figured it out how to integrate it into one parent handler. Right now I have my modified one for the THs and your unmodified one for all of my other ones. I can send you a pull request if want to take a look.

BrettSheleski commented 5 years ago

Well it looks like you got the hard part all figured out, now it's just a matter of organization.

First, lets create a new Device Handler. Let's call it Tasmota-Temperature.

What we'd need to do is create a new DeviceHandler. Here's some code to get you started:

metadata {
    definition(name: "Tasmota-Temperature", namespace: "BrettSheleski", author: "Brett Sheleski") {
        capability "Temperature Measurement"
    }

    // UI tile definitions
    tiles {
        valueTile("temperature", "device.temperature", width: 2, height: 2) {
            state("temperature", label:'${currentValue}°', unit:"F",
                backgroundColors:[
                    [value: 31, color: "#153591"],
                    [value: 44, color: "#1e9cbb"],
                    [value: 59, color: "#90d2a7"],
                    [value: 74, color: "#44b621"],
                    [value: 84, color: "#f1d801"],
                    [value: 95, color: "#d04e00"],
                    [value: 96, color: "#bc2323"]
                ]
            )
        }
        main "temperature"
        details "temperature"
    }
}

def initializeChild(Map options){
    // when the 'Master' device creates child devices, this method is called passing configuration
}

def updateStatus(status){
    // when the 'Master' device refreshes it passes the retrieved status to all children, thus calling this method
    // update the status of this device accordingly
}

Once this is done the Tasmota device handler would need to be modified to something like the following:

// ...
 switch (moduleId){

// ...

        case 28: // Sonoff T1 1CH
        case 41: // Sonoff S31
            devices[parentId + '-Power'] = [namespace : "BrettSheleski", type: "Tasmota-Power", label : "${thisLabel} Switch", options : [powerChannel : 1]];
            break;

        case 4: // Sonoff TH
            devices[parentId + '-Power'] = [namespace : "BrettSheleski", type: "Tasmota-Power", label : "${thisLabel} Switch", options : [powerChannel : 1]];
            devices[parentId + '-Temperature'] = [namespace : "BrettSheleski", type: "Tasmota-Temperature", label : "${thisLabel} Temperature"];
            break;

        case 5: // Sonoff Dual
        case 19: // Sonoff Dev

// ...

And then some similar code will need to be modified to read the GPIO configuration. See the getGpioDevices() method in Tasmota.groovy.

Doing the above will allow any and all Tasmota-devices be assigned the generic "Tasmota" Device Handler which will conditionally spawn the appropriate child devices given the module and gpio configuration. This way there's no need to create a whole ton of different device handlers for all the different possibilities of combinations of modules and/or gpio settings.

Sym-Link commented 5 years ago

Hey Brett,

Sorry for the late response. Decembers are usually pretty crazy for me. I see exactly what you are saying. I will see if I can get done when I have some extra time. Do you think that the temperature and humidity should be separate child devices or could they be combined into one for temp and humidity?

Actually, never mind on that question. I re-read you pull comment and there you say that they two should be separate childs.

BrettSheleski commented 5 years ago

I asked myself the same thing, not sure what the right answer is. My first inclination would be to separate them to two different device handlers.

Sym-Link commented 5 years ago

Ok, I will do that. Separating would give them their own tiles with their reading front and center.

BrettSheleski commented 5 years ago

True, and I could see situations where a module has just a Temperature sensor or just a Humidity sensor and not the other. In those cases it wouldn't make sense to create a SmartThings device indicating that it does have the other. That would just lead to confusion by the user.