ITEAD Sonoff switches and sockets - cheap ESP8266 Wifi+MQTT hardware

Thanks man, I could do it by rules.

@Confectrician Jerome,

Thanks for the information. Did you ever find your AliExpress part number for the pogo pins? THere are so many kinds and they have an assortment of diameters pin end types, etc. Just trying to pare down the possibility of getting pins that are way off the mark.

Cheers!

Mike

I have to apologize.
I totally forgot about this.

Here are the pins i have ordered.
http://s.aliexpress.com/ABz6FZfI

Thx!

Hi All,

Can someone confirm if this module Sonoff-Home-WiFi-Wireless-Smart-Switch-5V-Relay-Module is supported by the Tasmota firmware?

The product is advertised as “1 Channel Inching/self-locking Switch” on Itead’s web site. I own the 5V version (the thinner one). There is also a 5V/12V version.

The board has two micro switches, one for setting the module function (1. classic on/off switch or 2. “inching” mode), and the command button which triggers the on/off command.
In “inching” mode, the command button first changes the state and then after one second it reverts back to the initial state.

Thanks!

Yes it is
The middle one on the tasmota wiki:

image

Thank you! I was looking on the right side column, but there it was right under my nose :slight_smile:

Can anyone tell me, if i can use this tasmota switches and maybe a power supply for 5v/12v in a waterproof case outdoors?

It can get cold to about -20 / -25°C in winter and hot about near to 40°C in summer.

Will this live long or will this only work for short time in this outdoor use?


I have KNX installation inside my house, but in my garden i only have few power lines, so i can´t make them all switchable. I have to use always power on wires and additional actors/tasmota switches outdoor near the devices i want to switch.

Yes you can.
The sonoff will not live forever if the wifi signal is very weak though. There seem to be an issue with the wearing out of the wifi power module in the sonoff after a while.

Please see the video below for tips about making your tasmota weather proof:

@ThomDietrich,

I am using a 4CH Pro (R1) to control a ceiling fan. I have it set up in self-locking mode. I have the fan light on Ch.4. Low fan speed is Ch. 1. High fan speed is Ch. 3. For medium I need to turn on Ch.1 and Ch. 2 at the same time (this is due to how the fan speed capacitor block is wired).

I am getting ready to flash TASMOTA on the device. I have flashed several Sonoff Basics and configured these devices as Switch Items in openHAB using MQTT.

My question is whether it is possible to send multiple MQTT commands via a single Switch Item. For example, when I set the fan to high speed (Ch. 3), I want to make sure I turn off Ch. 1 and Ch. 2 and then turn on Ch. 3 as a single action. Similarly, if I want to set the fan speed to medium, I want to turn off Ch. 3 and turn on both Ch. 1 and Ch. 2. A final example, turn the fan off and the light off, I want to turn all four channels off as a single action.

I suppose I could do this with rules by using virtual switches to trigger a rule to send separate commands to each channel. I was just thinking that it would be “cleaner” in the Item definition so that the state of the physical channels “follows” just as it does with the single relay Sonoff Basic.

Thanks to you and to the broader community for any insights on this.

Regards.

Mike

There are two answers to this question.
Yes you can add as many mqtt binding instructions to an item as you want.
I also believe there is an exclusive mode on tasmota where only one switch is on at a time but I maybe mistaken

OK, I’ll give it a go on multiple mqtt instructions.

The only exclusive at play in my setup is (1 OR 2) AND (NOT 3). I suppose it’s not a bad idea to have a safeguard… but if this kind of logic isn’t supported then it’s by no means a show stopper.

@vzorglub Vincent,

OK, I have Items defined to send multiple MQTT messages for a single Item definition.

My next issue is to get the UI to “follow” the state of the channels properly.

Here are my item definitions:

Switch      SPT_house_FF_backbr_ceiling_light_fan
            "Back Bedroom Fan Light"
            [Switchable]
            { mqtt=">[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER4:command:*:default],
                    <[openhab_tcpbroker:stat/sonoff-backbr_fan/POWER4:state:default]" }
Switch     SPT_house_FF_backbr_ceiling_off_fan
            "Back Bedroom Fan Off"
            [Switchable]
            { mqtt=">[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER1:command:*:0],
                    >[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER2:command:*:0],
                    >[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER3:command:*:0],
                    <[openhab_tcpbroker:stat/sonoff-backbr_fan/POWER1:state:default],
                    <[openhab_tcpbroker:stat/sonoff-backbr_fan/POWER2:state:default],
                    <[openhab_tcpbroker:stat/sonoff-backbr_fan/POWER3:state:default]" }
Switch      SPT_house_FF_backbr_ceiling_low_fan
            "Back Bedroom Fan Low"
            [Switchable]
            { mqtt=">[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER1:command:*:default],
                    >[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER2:command:*:0],
                    >[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER3:command:*:0],
                    <[openhab_tcpbroker:stat/sonoff-backbr_fan/POWER1:state:default]" }
Switch      SPT_house_FF_backbr_ceiling_medium_fan
            "Back Bedroom Fan Medium"
            [Switchable]
            { mqtt=">[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER1:command:*:default],
                    >[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER2:command:*:default],
                    >[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER3:command:*:0],
                    <[openhab_tcpbroker:stat/sonoff-backbr_fan/POWER2:state:default]" }
Switch      SPT_house_FF_backbr_ceiling_high_fan
            "Back Bedroom Fan High"
            [Switchable]
            { mqtt=">[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER1:command:*:0],
                    >[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER2:command:*:0],
                    >[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER3:command:*:default],
                    <[openhab_tcpbroker:stat/sonoff-backbr_fan/POWER3:state:default]" }

        Switch item=SPT_house_FF_backbr_ceiling_light_fan   icon="light"
        Switch item=SPT_house_FF_backbr_ceiling_off_fan     icon="fan"  mappings=[0="OFF"]
        Switch item=SPT_house_FF_backbr_ceiling_low_fan     icon="fan"
        Switch item=SPT_house_FF_backbr_ceiling_medium_fan  icon="fan"
        Switch item=SPT_house_FF_backbr_ceiling_high_fan    icon="fan"

I’ve tried multiple permutations for the incoming (<) portions of each Item definition. None that I have tried set the UI properly. If Low is on, clicking on High doesn’t turn the Low switch off. If the fan is on, clicking the Off switch doesn’t turn off the UI switches. But, as I said, the actual physical action works like I want it to.

I’d rather the “Fan Off” switch be a momentary pushbutton… but setting an “Off” mapping didn’t work. If I click on the button, the proper outgoing MQTT messages are sent and the device turns off the relays. But the button state and the MQTT messages aren’t sent. If I leave it as a switch slider, then clicking the slider toggle sends the MQTT messages.

Also, when I click a button on the physical device itself, they UI does not update to reflect the action taken on the device.

What am I missing?

Thanks.

Mike

UPDATE - I may have spoke too soon regarding the definitions performing the correct physical actions. The “control” outgoing MQTT messages work… mostly. But it’s not quite right. If I turn on “Low” (Ch. 1), then I turn on “High” (Ch. 3), Ch. 3 comes on and Ch.1 turns off as desired. But, the UI for “Low” does not update so the switch is still on. If I then click the “Off” switch (Ch. 1), Ch.1 was physically already off… but the UI action causes the defined MQTT messages to be sent… which means that turning off “Low” ends up sending a turn off “High”. I think this would all be resolved if I can get the UI to “follow” properly.

Why don’t you try a:

String Item SPT_house_FF_backbr_ceilingfan_state

In the sitemap use a selection type:
and remove your switches

Selection  item=String Item SPT_house_FF_backbr_ceilingfan_state "label="ceiling fan state" mappings=["OFF="OFF", "LOW"="LOW", "MEDIUM"="MEDIUM", "HIGH"="HIGH"]

And then a rule: (install the mqtt action)

rule "ceiling fan"
when
    String Item SPT_house_FF_backbr_ceilingfan_state changed
then
    val String fanState= triggeringItem.state.toString
    if (fanState == "OFF") SPT_house_FF_backbr_ceiling_off_fan.sendCommand(OFF)
    if ....
end

Then we will work on the feedback from the fan

@vzorglub Vincent,

OK, that’s definitely a more stable, and intuitive, setup for controlling the speed. Thanks!

Just for future reference, here’s the rule syntax.

rule "Ceiling Fan"
when
    Item SPT_house_FF_backbr_ceiling_state_fan changed
then
    val String fanState = SPT_house_FF_backbr_ceiling_state_fan.state.toString
    if (fanState == "OFF") SPT_house_FF_backbr_ceiling_off_fan.sendCommand(OFF)
    if (fanState == "LOW") SPT_house_FF_backbr_ceiling_low_fan.sendCommand(ON)
    if (fanState == "MEDIUM") SPT_house_FF_backbr_ceiling_medium_fan.sendCommand(ON)
    if (fanState == "HIGH") SPT_house_FF_backbr_ceiling_high_fan.sendCommand(ON)
end

I’m not sure what you meant by this. Is there something I should install besides the MQTT binding?

Now as to the feedback from the fan in order to make the Sitemap Selection correspond to that actual state of the fan (if the action is taken on the switch instead of through the UI). I’m guessing you already have thoughts on how to address this. Yes?

Cheers!

Mike

Ignore that, I was going to try another approach and decided otherwise

Now for the feedback…

Put your 4 items in a group.

Group Switch SPT_house_FF_backbr_ceiling_light_fan_group

Switch      SPT_house_FF_backbr_ceiling_light_fan
            "Back Bedroom Fan Light" (SPT_house_FF_backbr_ceiling_light_fan_group)
            [Switchable]
            { mqtt=">[openhab_tcpbroker:cmnd/sonoff-backbr_fan/POWER4:command:*:default],
                    <[openhab_tcpbroker:stat/sonoff-backbr_fan/POWER4:state:default]" }
...

And a new rule:

rule "fan feedback"
when
    Member of SPT_house_FF_backbr_ceiling_light_fan_group changed
then
    var String itemName = triggeringItem.name.toString
    if (itemName.contains("off") && triggeringItem.State == OFF) SPT_house_FF_backbr_ceiling_state_fan.postUpdate("OFF")
    else {
        if (triggeringItem.State == ON) {
            var String speed = itemName.split("_").get(5)
            postUpdate("SPT_house_FF_backbr_ceiling" + speed + "_fan". speed.toUpperCase())
        }
    }
end

@vzorglub Vincent,

The rule as you sent ended up always turning off the fan. I’ve been trying to adjust the logic but it either does nothing or I get into a race situation where the change triggers the original rule and that in turn triggers the feedback rule and away we go looping endlessly.

It could be that what the rule is intended to do is failing and thus that is causing it not to perform the desired action which is what either makes it not do anything or in turn expects a setting of a value and when it doesn’t, it triggers the endless loop. I say this because the postUpdate logs an error

An error occurred during the script execution: Could not invoke method: org.eclipse.smarthome.model.script.actions.BusEvent.postUpdate(java.lang.String,java.lang.String) on instance: null

This rule logic differs from what you sent as it is one of my logic iterations. I commented out the last postUpdate in the rule to get out of the endless loop.

rule "Ceiling Fan Feedback"
when
    Member of SPT_house_GP_backbr_ceiling_fan changed
then
    logDebug("SPT_house", "Running rule Ceiling Fan Feedback")

    var String itemName = triggeringItem.name.toString
    logInfo("SPT_house", itemName + " triggered Ceiling Fan Feedback rule.")
    if (itemName.contains("off") && triggeringItem.state == OFF)
    {
        logInfo("SPT_house", "Turning off ceiling fan.")
        postUpdate(SPT_house_FF_backbr_ceiling_state_fan, "OFF")
    }
    else
    {
         var String speed = itemName.split("_").get(5)
         if (triggeringItem.state == ON)
         {
             logInfo("SPT_house", itemName + " is on.")
             postUpdate("SPT_house_FF_backbr_ceiling_" + speed + "_fan", ON)
         }
//         postUpdate("SPT_house_FF_backbr_ceiling_state_fan", speed.toUpperCase())
    }
end

Can your highly experienced coding eyes spot the issue?

Thanks.

Mike

Can you show me the log when you change the fan speed manually, please?

To avoid the loop change the trigger to the first rule:

rule "Ceiling Fan"
when
    Item SPT_house_FF_backbr_ceiling_state_fan received command
then
    val String fanState = receivedCommand.toString
    if (fanState == "OFF") SPT_house_FF_backbr_ceiling_off_fan.sendCommand(OFF)
    if (fanState == "LOW") SPT_house_FF_backbr_ceiling_low_fan.sendCommand(ON)
    if (fanState == "MEDIUM") SPT_house_FF_backbr_ceiling_medium_fan.sendCommand(ON)
    if (fanState == "HIGH") SPT_house_FF_backbr_ceiling_high_fan.sendCommand(ON)
end

Hi all,
I´m on holidays and as I have time now I brought my laptop, a tplinkrouter, some sonoff devices and FTDI interface with me to do some programming.

Months ago I allready flashed the sonoff devices at home with Tasmota via platformio-ide on WIndows 7 according to my home WLAN. worked prefectly without any problems. Meanwhile i run Windows 10 and yesterday I tried to flash the sonoff touch ans 4ch again with newly installed ATOM without success. I then went over to Arduino IDE - compiled and flashed … again without sucess. I´m quite desperate and wanted to if anybody could help finding the problem?
Laptop: Sony Vaio running Win10
Devices: Sonoff touch and 4ch
Please see pictures of the devices and config.

IMG_20180710_094403IMG_20180710_094442IMG_20180710_094512IMG_20180710_094502
I´m really looking forward for your suggestions.