Sending data to a USB port to interface with a wireless switch

[akbooer]

@therealdb

I've just added Shelly bridge support for Shelly 1/1PM (I think) in development v21.3.28.

If you're able to check, that would be great.

If it's all OK, then I'll move on to the others.

[therealdb]

@akbooer I'll try it later tomorrow, since this is a family movie night. meanwhile, here's a couple of messages from my broker:

tasmota/discovery/id

config = {"ip":"192.168.1.50","dn":"tasmota-dehum","fn":["tasmota-dehum",null,null,null,null,null,null,null],"hn":"tasmota-dehum","mac":"XXX","md":"Sonoff TH","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"9.3.1","t":"tasmota-dehum","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[1,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":1,"lt_st":0,"sho":[0,0,0,0],"ver":1}

sensors = {"sn":{"Time":"2021-03-26T23:48:03","SI7021":{"Temperature":15.8,"Humidity":73.4,"DewPoint":11.0},"TempUnit":"C"},"ver":1}

--

config = {"ip":"192.168.1.53","dn":"tasmota-watertank","fn":["tasmota-watertank",null,null,null,null,null,null,null],"hn":"tasmota-watertank","mac":"ECFABC5F0A29","md":"Generic","ty":0,"if":0,"ofln":"Offline","onln":"Online","state":["OFF","ON","TOGGLE","HOLD"],"sw":"9.3.1","t":"tasmota-watertank","ft":"%prefix%/%topic%/","tp":["cmnd","stat","tele"],"rl":[0,0,0,0,0,0,0,0],"swc":[-1,-1,-1,-1,-1,-1,-1,-1],"swn":[null,null,null,null,null,null,null,null],"btn":[0,0,0,0,0,0,0,0],"so":{"4":0,"11":0,"13":0,"17":0,"20":0,"30":0,"68":0,"73":0,"82":0,"114":0,"117":0},"lk":1,"lt_st":0,"sho":[0,0,0,0],"ver":1}

sensors = {"sn":{"Time":"2021-03-15T13:47:43","DS18B20":{"Id":"3C01D6070BEA","Temperature":15.3},"SR04":{"Distance":58.351},"TempUnit":"C"},"ver":1}

--

sensors = {"sn":{"Time":"2021-03-28T09:21:22","BME280":{"Temperature":20.2,"Humidity":50.0,"DewPoint":9.4,"Pressure":967.1},"TSL2561":{"Illuminance":113.900,"IR":2135,"Broadband":6591},"PressureUnit":"hPa","TempUnit":"C"},"ver":1}

--

sensors = {"sn":{"Time":"2021-03-28T09:21:22","BME280":{"Temperature":20.2,"Humidity":50.0,"DewPoint":9.4,"Pressure":967.1},"TSL2561":{"Illuminance":113.900,"IR":2135,"Broadband":6591},"PressureUnit":"hPa","TempUnit":"C"},"ver":1}

Status are published under tele/devicename

STATE = {"Time":"2021-03-28T19:17:42","Uptime":"13T06:19:46","UptimeSec":1145986,"Heap":23,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":84,"POWER":"OFF","Wifi":{"AP":1,"SSId":"XXX","BSSId":"XXX","Channel":12,"RSSI":60,"Signal":-70,"LinkCount":3,"Downtime":"0T00:01:32"}}


SENSORS = {"Time":"2021-03-28T19:17:42","DS18B20":{"Id":"3C01D607ACFE","Temperature":13.8},"TempUnit":"C"}

The format of sensors is very similar to discovery, but more compact.

There's also tele/device/LWT (Online, Offline) to handle "Last Will and Testament". I'm using it to notify of device being dropped out of the network via CommFailure and similar.

I'm sure @ArcherS has many more sensors than me.

[ArcherS]

I have some 10 Tasmota devices with a number of different sensors reporting temperature etc. It is very easy to combine the sensors on one device, the information for all attached sensors are included in one SENSOR message for that Tasmota device.

Some data from them:

AM2301 (temp, humidity and dew point temp)
tele/tasmota_E0395C/SENSOR = {"Time":"2021-03-28T19:56:35","AM2301":{"Temperature":5.7,"Humidity":64.6,"DewPoint":-0.5},"TempUnit":"C"}

DS18B20 (temp) Four DS18B20 connected to one Tasmota
tele/tasmota_2ECD0B/SENSOR = {"Time":"2021-03-28T19:49:06","DS18B20-1":{"Id":"000005B4E469","Temperature":5.8},"DS18B20-2":{"Id":"3C01D60701B8","Temperature":17.9},"DS18B20-3":{"Id":"3C01D6074A47","Temperature":20.3},"DS18B20-4":{"Id":"3C01D6079246","Temperature":9.3},"AM2301":{"Temperature":5.4,"Humidity":75.0,"DewPoint":1.3},"TempUnit":"C"}

and in a device that also has an AM2301, since it is only one DS18B20 it does not get the "-nn" suffix
tele/tasmota_845CBC/SENSOR = {"Time":"2021-03-28T20:11:35","DS18B20":{"Id":"000005B5E8ED","Temperature":12.0},"AM2301":{"Temperature":11.2,"Humidity":40.6,"DewPoint":-1.7},"TempUnit":"C"}

BME280 ( temp, humidity, dew pont temp, air pressure) and BH1750 (light sensor in lux) in one device
tele/tasmota_81FF56/SENSOR = {"Time":"2021-03-28T19:49:35","BME280":{"Temperature":6.6,"Humidity":65.4,"DewPoint":0.5,"Pressure":1009.4},"BH1750":{"Illuminance":0},"PressureUnit":"hPa","TempUnit":"C"}

BLE sensors (temp, humidity, dew point temp) below three Xiaomi sensors identified by their MAC
tele/tasmota_F181DC/SENSOR = {"Time":"2021-03-28T20:01:38","ATC-f159bf":{"Temperature":21.5,"Humidity":48.0,"DewPoint":10.0,"Battery":69,"RSSI":-80},"ATC-9446bf":{"Temperature":22.6,"Humidity":42.0,"DewPoint":9.0,"Battery":83,"RSSI":-89},"ATC-6d5d44":{"Temperature":14.3,"Humidity":46.0,"DewPoint":2.8,"Battery":63,"RSSI":-84},"TempUnit":"C"}

MH-Z19B C02 meter (CO2 and temp) below in a device that also has a AM2301
tele/tasmota_7EC9D9/SENSOR = {"Time":"2021-03-28T20:03:49","AM2301":{"Temperature":20.7,"Humidity":48.1,"DewPoint":9.3},"MHZ19B":{"Model":"B","CarbonDioxide":655,"Temperature":22.0},"TempUnit":"C"}

[Buxton]

@akbooer Tasmota energy sensor

{
  "Time": "2021-03-28T21:51:01",
  "ENERGY": {
    "TotalStartTime": "2020-06-07T00:10:43",
    "Total": 2356.063,
    "Yesterday": 7.056,
    "Today": 6.459,
    "Period": 24,
    "Power": 285,
    "ApparentPower": 302,
    "ReactivePower": 99,
    "Factor": 0.95,
    "Voltage": 123,
    "Current": 2.453
  }
}

[ArcherS]

And a Tasmota IR receiver that can also be used for HVACs.
IR remotes for HVACs are a bit special, they send/receive all data fields every time.

Received IR from a Logitech remote:
tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"NEC","Bits":32,"Data":"0x10EF08F7","DataLSB":"0x08F710EF","Repeat":0}}

Received from a noname led-lights remote:
tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"LUTRON","Bits":3,"Data":"0x700000000","DataLSB":"0xE000000000","Repeat":0}}

The Tasmota IR receive/transmitter also supports HVAC remotes, this is an example of a received message from my Fujitsu remote:
tele/tasmota_E0D649/RESULT = {"IrReceived":{"Protocol":"FUJITSU_AC","Bits":128,"Data":"0x0x1463001010FE0930400400000000206C","Repeat":0,"IRHVAC":{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}}}

I have not tested sending yet since my Mqtt is not fully up and running yet, but it should be something like this:
IRsend{"Protocol":"NEC","Bits":32,"Data":"0x10EF08F7","DataLSB":"0x08F710EF","Repeat":0}

and for IRHVAC:
IRHVAC{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":20,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}

[therealdb]

@akbooer shelly 1 seems to be good, but I'm mostly using them as binary sensors (shelly 1 can detach the input from the button, so it's very handy ie for doorbell, PIR or similar, since it's 12v or 110/220).

It also discovered my shelly plug, but as a scene controller. Here's the info part:

{"wifi_sta":{"connected":true,"ssid":"XXX","ip":"192.168.1.46","rssi":-47},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"08:57","unixtime":1617001074,"serial":30,"has_update":false,"mac":"XXXX","cfg_changed_cnt":12,"actions_stats":{"skipped":0},"relays":[{"ison":true,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"source":"timer"}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1617008274,"counters":[0.000, 0.000, 0.000],"total":0}],"temperature":31.77,"overtemperature":false,"tmp":{"tC":31.77,"tF":89.18, "is_valid":true},"update":{"status":"idle","has_update":false,"new_version":"20210323-105718/v1.10.1-gf276b51","old_version":"20210323-105718/v1.10.1-gf276b51"},"ram_total":50632,"ram_free":38444,"fs_size":233681,"fs_free":166413,"uptime":222282}

It's a plug with KWH and internal temp sensor, for overheat protection.

[therealdb]

I will also probably just send an announce message upon start of the broker. This will enable automatical discover of new devices, with no user intervention.

[akbooer]

@therealdb said in MQTT – setup and use:

shelly 1 seems to be good, but I'm mostly using them as binary sensors (shelly 1 has the ability to detach the input from the button

Yes, I think all their switches can do that. I’ll add the appropriate logic to give each child device the scene controller variables.

[akbooer]

I think we need a separate Tasmota thread, or this will get confusing.

@therealdb for the Shelly input devices I see:

  for switch in "momentary" mode: 
  input_event/n = {"event":"S","event_cnt":11}
		S = shortpush 	
		L = longpush 	
		SS = double shortpush 	
		SSS = triple shortpush 	
		SL = shortpush + longpush 	
		LS = longpush + shortpush 	

and this can be for multiple inputs (eg. ix3 has three.)

So we need to agree on how to map these to scene numbers. Perhaps the easiest thing is to repesent each one by increments of 10.

For example:

    scene_no = {
		S = 10,  -- shortpush 	
		L = 20,  -- longpush 	
		SS = 30, -- double shortpush 	
		SSS = 40,  -- triple shortpush 	
		SL = 50, -- shortpush + longpush 	
		LS = 60, --longpush + shortpush 
    }	

so a short push on button 0 would be 10, a long push on button 1 would be 21.

[akbooer]

After an embarassing three attempts, v21.3.29c has this multi-push scene numbering implemented for shelly-ix3 (only, at the moment.)

[therealdb]

@akbooer yeah, I think the numbering is OK.

What I was referring to detached mode is that when in this mode, you have input and switch not in sync, so imho we should map them as a BinarySwitch and a generic security sensor for the input. You'll get both \input and \relay mqtt message.

I think it's OK to discuss Tasmota in this thread, since it's basically all dedicated to MQTT

[akbooer]

@therealdb said in MQTT – setup and use:

we should map them as a BinarySwitch and a generic security sensor for the input.

Can't be a generic security sensor if you want to capture the different switch press modes, so I think just the sl_SceneActivated and time makes more sense.

[Crille]

Just wanted to say big thanks to all for the great work!
I've read all the progress with the broker and Tasmota bridge with joy and now managed to switch my Sonoffs from rules and Virtual HTTP Devices completely to MQTT using homebridge-mqttthing and Virtual Sensor plugin.

[akbooer]

@crille

Excellent news. Yes, I am using homebridge-mqttthing too, for my few-remaining Zwave devices bridged to openLuup from Vera. The Homebridge-Shelly accessory is also very functional.

All this means that the Apple Home app is my primary UI (well, actually secondary, since Siri on the HomePod takes care of most things.)

[rafale77]

Awesome to see the MQTT implementation. Only if I could get myself the motivation to migrate to homebridge and get everything (Z-way/openLuup/HomeAssistant/Homebridge) to talk through MQTT instead of http as they are at the moment... It seems to be a lot of work...

For me too, the Apple Home app has become my primary (yet rarely used) UI.

[Crille]

@akbooer said in MQTT – setup and use:

for my few-remaining Zwave devices bridged to openLuup from Vera

I'm trying to get rid of the old Vera plugin for Homebridge.

What topics do I put in mqttthing to get/set bridged Vera devices?
I got the "getOn" to reflect the status when I had luup.attr_set ("openLuup.MQTT.PublishVariableUpdates", true) in the Lua Startup Code, is that necessery for this purpose?
Do I need to write a handler for this?
I tried a generic handler but never got it to work.
Do you have an example of a handler if it's required?

[akbooer]

@crille said in MQTT – setup and use:

What topics do I put in mqttthing to get/set bridged Vera devices?

Depends what you want to get/set. Currently, I'm just using this for on/off switches, so using the mqttthing type Light bulb - on/off. I'm sure you can be more sophisticated, but I haven't tried it.

As an example, I'll use a Vera-attached Zwave switch (device #30186 – it's actually a Fibaro relay, but it could be anything)

The first thing you need to ensure is that you have set the openLuup MQTT server to publish variable updates, using this line in Lua Startup:

luup.attr_set ("openLuup.MQTT.PublishVariableUpdates", true)   -- publish variable updates

So, then, in order to reflect the relevant variable in the mqttthing you need in MQTT Topics :

• Get on – openLuup/update/30186/SwitchPower1/Status

and in order to control it:

• Set on – relay/30186

The relay command above is just a convenient openLuup shortcut to turn devices on/off which works both in MQTT and as an HTTP request.

That should be all for basic control.

[Crille]

@akbooer Thank you, I never understood that the relay/ command was available to MQTT as well.
I guess there's no easy way to handle setBrightness?

[akbooer]

I knew that was going to be the next question... I’ll add something modelled after the Shelly commands (like /relay,except that this takes 1 and 0 as arguments instead of turn=on, etc.)

[akbooer]

@Crille

OK, latest development version (21.4.28c) has HTTP and MQTT requests to change a dimmer:

for device #51 to brightness level 42:

HTTP:

http://openLuupIP:3480/light/51?brightness=42

MQTT:

• topic: light/51
• message: 42

There's been some fairly drastic internal refactoring of the openLuup API, but you shouldn't notice anything changed...