Thought it could be good for future users to give a short write up on how to set up Tasmota devices reporting sensors into OpenLuup with the new Tasmota bridge.

First setup the Tasmota device:
Browse to the Tasmota device IP and then select "Configuration"
Go into Configuration Other
Make sure "Mqtt enable" is set and give a Device Name
Then into Configuration MQTT
Give IP adress and port of OpenLuup Mqtt server
Give a Client name
Set user and password
Set topic name

If you want to change how often the Tasmota device pushes data over Mqtt you can do that in the Console for the Tasmota by using the "TelePeriod" command. By default TelePeriod is set to 300 seconds, e.g. "TelePeriod 60" sets it to once every minute. (Just typing "TelePeriod" shows the current value.)

Second set up OpenLuup:
Paste the following into Lua Startup:

luup.attr_set ("openLuup.MQTT.Port", 1883)
luup.attr_set ("openLuup.MQTT.Username", "luup")
luup.attr_set ("openLuup.MQTT.Password", "password")
luup.attr_set ("openLuup.MQTT.PublishVariableUpdates", true) -- Not requred for Tasmota, publish every variable update if wanted

Save and reload Luup engine, you should now get the Tasmota bridge in OpenLuup

You should also get the Tasmota device you setup above
On my OpenLuup it got placed in the room "Tasmota".

Next step is to set up devices for the sensor data you want to get from the Tasmota device. This data is pushed into variables for the Tasmota device (if you hover above a variable name you see the sensor, e.g. "BME280"):

Download the plugin "Virtual Sensor" if you do not have it.
Go into Virtual Sensors, tab "Virtual Sensors" and create the new virtual sensors you need for the data you want to display from the Tasmota device, you want one virtual sensor per value.

Next step is to set the data from the Tasmota variables to the corresponding virtual sensors.
Go into the Virtual Sensor plugin, into the tab "Virtual Sensors"
Select the Tasmota device in the first drop down and then the variable in the second:

Job done! Now repeat for all the variables you wish to add into OpenLuup.

@therealdb I built my outdoor sensor from what I had in the garage, very much DIY in other words.
I used an outdoor junction box, to this I hot glued a plastic dome from an old motion sensor for the light sensor. I also added a short piece of plastic pipe for the BME280 so that it is outside of the box to get better readings. To keep spiders etc out of the pipe I added an old stainless mesh dome to the end of it.
In the box is also a 240V/5V transformer.

The intention is to mount it on the north wall of the house outside of the sun. At the moment it is laying on the window sill.

Some more small tips on rules:
It is possible to create up to three rules for each sensor.
It is possible to have several "Do" stamements in each rule.
Rule<x> ON <trigger1> DO <command> ENDON ON <trigger2> DO <command> ENDON ...

It is very easy to find out the name of each sensor for using in the rules by looking at: http://IP_address/cm?cmnd=Status%2010

A rule is defined by pasting the rule from e.g. notepad to the Console window of the sensor.
After that the rule needs to be enabled by Rule1 1, Rule2 1 etc.
After enabling a rule check in the console that the rule is sending values.
A rule is deactivated by Rule1 0 etc.
To see the contents of a rule just type Rule1 etc.
To delete a rule type Rule1 " etc.

My recommendation is for people to look at the Tasmota rules documentation, it is very good.
.
//ArcherS

Thank's for a really quick reply! That indeed did the trick, I knew it was something easy I missed.
Now I just need to go through my Reactors and re-map my z-way devices. Not too much work.

//ArcherS

Checked with v20.7.14 and the "sl_CentralScene" variable is updated with the key pressed.

Thanks again for the update!

Some time ago I stumbled on some rather nice looking temperature and humidity sensors from Xiaomi and how to get them to communicate with a Tasmota ESP32 with BLE.

I ordered an ESP32 on Ebay and a three-pack of the sensors from Bangood. The sensors are quite cheap, you can find them for €4-5 in the usual sites.

The sensors are quite small, approx 4.5cm and run on a CR2032 battery. Time will tell how long the batteries will last. With the custom firmware you can change the reporting interval.

I have now been running this for little over two months and it works surprisingly well, bringing the temperature and humidity data into OpenLuup.

In short what you do is the following:

• Download the beta Tasmota for ESP32, flashing is a bit different from the regular Tasmota but pretty straight forward

• Enable bluetooth with setoption115 1

• The Xiaomi sensors can used both with stock firmware and flashed with a custom firmware that removes the encryption from the transmit of data, I flashed them with a Win10 laptop and it was super easy. You can even roll back the original firmware if you want.

The Xiaomi sensors will then be included by the ESP32 Tasmota device and can be sent to OpenLuup with rules, brought in with Sitesensor or now via MQTT.

It seems as if it is possible to modify it with an external antenna.
Here is an article on how to modify the Razberry2 EU:
Modify Razberry2 (translated)

Is is in Swedish, hopefully the translated text is understandable.
In short you cut away the built-in antenna and solder on an antenna connector for the external antenna. You of course need an antenna for the frequency in your country, the article is for 868 MHz (EU).

//ArcherS

@matteburk if you have a Pi 3B+ then you are in luck since it will boot from USB without doing anything.
If it is a Pi 3B then you have to change a "USB boot bit", see e.g. this instruction.

I took the easy route and bought a new Pi 3B+ when I moved my Z-way server to SSD from SD. They are quite cheap anyway and I guess I can get use of the Pi 3B for something else later on.

As @toggledbits says the Pi's are a bit picky on SSD adapters. I had two old 2.5" cases laying around, one worked and the other did not. The SSD migration cable that came with a Samsung SSD that I used for another PC also works.

Edit: And if you buy a new Pi 4 they should now also have USB boot out of the box. Assuming the box has not been sitting on the shelf in the store for too long of course.

@akbooer thanks for the assistance and patience, now it works!

Edit: Added the humidity to the code:

local json = require "openLuup.json"

function MyMQTThandler (topic, message)
  local info = json.decode (message)
  local t = info.AM2301.Temperature
  local h = info.AM2301.Humidity
  luup.variable_set ("urn:upnp-org:serviceId:TemperatureSensor1", "CurrentTemperature",  t, 216)
  luup.variable_set ("urn:micasaverde-com:serviceId:HumiditySensor1", "CurrentLevel",  h, 228)
end

luup.register_handler ("MyMQTThandler", "mqtt:tele/tasmota_test/SENSOR")

@buxton yes it opens up new possibilities. On the Tasmota bluetooth webpage some other devices are listed, e.g. a soil humidity meter.

So far it has been quite stable for more than two months.
The Tasmota ESP32 is still beta, I assume it will get better over time.

I will also make the ESP32 to report over Mqtt now that OpenLuup has support for it, hopefully that will make the setup even more stable.

@rafale77 I tried this way of delaying at startup and it works fine. It does not cause delays when reloading luup which is a clear benefit.

Just for fun I decided to test and setup Home Assistant OS on two virtual machines.

The first is a HA OS VM on a Windows 10 i5 NUC with VirtualBox. Quite easy to setup, some information can be found on the HA website, I also looked at this guide.

The second VM I installed on an old Core2 PC. I installed Proxmox and then HA OS in a VM. A bit more complicated to setup but there is a good guide here. The Core2 seems ok for this setup, in comparison with the old Athom PC that did not do the job.

Both installations seem to work ok. I will test them later on with a backup of my production setup to see if that changes anything.
The Windows installation got corrupted when I had to hard reset the PC. As expected HA OS did not like that, however quite easy just to delete the VM and set it up again. I only had a test installation of HA on the VM, but as always a backup of HA is a good idea.

I have not tested any USB devices (e.g. Zwave stick) since I do not use it. As far as I have understood it both should work with USB devices.

What to use? The plan is to stay with my current Debian/Docker setup since it has so far been very stable. If the HA devs continues to move away from the Docker installation I may need to reconsider this.

The other VM's could be an option for test rigs I think.
I like the Proxmox setup, it feels quite solid and is built for VM. The Windows setup feels a bit more uncertain with the MS Windows 10 automatic updates etc.

@cw-kid it is really difficult to say. I think your drawing looks quite similar to the one I posted, but not quite sure, it could be different. The earthing in the pattress box is unfamiliar with me, the boxes here are in plastic. But I assume it is simply an earth to the box since it is made of metal.

The colours are always tricky in old houses. They can have changed, different standards over time etc. Not to be trusted in other words. The only way to know is really to try understand what they all are and where they all go.
You may need to disconnect the cables on the two switches to fully map things out. Marking the original position of all cables, cutting the power while working etc.

I do not have any Dimmer 2, but will it not need neutral to operate? This means that you would need to get neutral to behind one of the light switches.

Another solution could be to put the Fibaro at the light instead, if it fits safely there and is allowed in your location. That could perhaps be a solution not having to get new cables drawn into the boxes.

Regarding your switches momentary should work or are even needed for being able to dim the light.

I found a sketch showing one way to connect two momentary switches to a Fibaro Dimmer (the older version I think since it says "O" for the connnection that goes to the light). Maybe it could be of use.
As always continue with care and cross-check with the Fibaro diagram, they could have changed something in the new version.

Basically if I understand the sketch correctly the two switches need to be connected in parallel over S1 and SX.

Not sure I can help more, good luck!

In Sweden the most usual connection in that situation is a "stairway connection". It typically is done like this:

Maybe what you have is something like this connection?

I am running HA Supervised in a Docker container on Debian on a small i5 Lenovo. Installed HACS without any problems, there are a few guides on how to do it.
It has been stable so far anyway.

The only concern I have is that it seems as if the HA developers want to push users away from the Docker way of running HA over to the HA OS way.
What this means is that the requirement now is more or less a vanilla Debian with only HA in Docker. If you do not stick to this the installation becomes "unsupported".
My installation was "supported" but now I can see that it has become "unsupported" due to the Portainer installation.
My idea was to add e.g. MSR in Docker at some point in time, but maybe the Docker route will be a dead end for HA?

It could be so that a HA OS installation on a VM, e.g. in Proxmox is the better choice in the longer run. The other option to only install HA OS on e.g. a fairly modern NUC seems a waste of resources to me since you cannot use it for anything else then.

I tested Proxmox and it seemed quite nice, the problem was that the old Athom PC I used was too old for the combination Proxmox/HA. So if I will go down that route I need to reinstall my i5 from scratch. Hmm.

To be honest I think it is a bit annoying that HA has complicated the setup/installation so much, not sure why they did that.

Answering my own question, perhaps of some use for someone else.

Today I upgraded my Home Assistant to 2021.11.5 and the connection to the OpenLuup Mqtt server seems so far to work as it should.
(Running on OpenLuup v21.11.8)

I have a setup that works quite nicely for controlling my "mini split" HVAC.
It is a quite old unit that is more or less totally stupid, it has a remote and that's it.

Some time ago I put together a Tasmota IR device that can control quite a few different HVAC units including mine. Pretty cheap, not too difficult to build and with a nice case it looks ok.

One nice aspect of the Tasmota solution is that both receives and sends IR so I mounted the IR Transciever close to the HVAC so that it also recieves commands from the IR remote. Another upside with the Tasmota route is that it is independent of what hub one uses since it is Wifi and Mqtt.

The next question was how to control it. With the help from @therealdb and his excellent VirtualDevices plugin together with the Mqtt capability of OpenLuup I managed to get a working solution in place.There is some information in the Mqtt Bridge thread on this.

Since I use Homewave the next logical step was to be able to control it from inside Homewave. A few dimmers with fixed steps and a Reactor with some logic and I got something working in place to control on/off, temperature and mode.
Not the prettiest solution but it does the job. The limitations in the old Vera gui and device types do show.

After recently having started playing around with Home Assistant I found a really nice integration for Tasmota IR HVAC control. It was really easy to get in place, it looks quite nice and can control most/all of the functions on the HVAC.

@toggledbits said in openLuup: MQTT server:

Also I can't connect my Home Assistant 2021.11.5 to the broker. This in the logs:

I may have missed this, but was this solved?

The reason is that I am currently on Home Assistant 2021.10.06 and was planning to upgrade to the latest 2021.11.5.
On 2021.10.6 I am using the Mqtt server in OpenLuup and it is working fine.

@Crille I do not use the MSR (yet! ), but I do have a Tasmota device reporting three Xiaomi Mi BLE devices to OpenLuup over Mqtt.

They report the following:

{"Time":"2021-11-24T16:00:25","ATC-6d5d44":{"Temperature":20.6,"Humidity":48.0,"DewPoint":9.2,"Battery":76,"RSSI":-89},"ATC-9446bf":{"Temperature":19.6,"Humidity":52.0,"DewPoint":9.5,"Battery":42,"RSSI":-84},"ATC-f159bf":{"Temperature":19.6,"Humidity":55.0,"DewPoint":10.3,"Battery":45,"RSSI":-84},"TempUnit":"C"}

on the following topic:

tele/TasmotaBLE/SENSOR

The message contains all three devices each under their name.

Not sure how about the syntax in MSR but in e.g. Home Assistant you write something in this direction in the config.yaml to retrieve the temperature for one device.

  - platform: mqtt
    name: "Temperatur"
    state_topic: "tele/TasmotaCO2Ax/SENSOR"
    value_template: "{{value_json['ATC-6d5d44'].Temperature}}"
    device_class: temperature
    unit_of_measurement: "°C"

@akbooer said in openLuup: Shelly Bridge plugin:

Can you give latest development (v21.11.8) a try?
I don't think I'm quite there yet, but the dimmer control should work to some extent.
This is surprisingly hard, since the status/control aspect of the Shelly dimmer is not quite the same as that of a ZWave one... I've always hated the way that Vera handled dimmers anyway! But I'm doing the best I can.

I installed v21.11.8 and now it almost seem to work.

In short what is not entirely in place is that the dimmer slider on the AltUI desktop in some cases does not follow the set value.

Example:
When I change the dim value in the Shelly GUI it updates in OpenLuup inside the dimmer but the slider on the desktop does not update.

Starting with the dimmer off and all sliders on 1% and then dim to 40% on the Shelly GUI gives:

In the Shelly GUI:

On the desktop in AltUI:

Inside the dimmer controller in AltUI:

Variables:

light/0/status:
{"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":40}

If I instead change the dim value from AltUI either from inside the dimmer controller or from the desktop it works and everything is updated. Also the slider inside the AltUI dimmer seems to work as it should.

Let me know if you need more information.

Based on your input I tested the latest fw (v1.11.4) on a Shelly Plug and it does indeed seem to work with Mqtt. Great news that it actually works now.

@akbooer said in openLuup: Shelly Bridge plugin:

Well, we'll see (the device arrived yesterday)...
Latest development version of openLuup (v21.11.2) has an initial attempt to service the Dimmer2 device:

inputs are handled exactly as the switch device – so, essentially, as a scene controller showing the latest activated scene: short press; long press; etc... This should work for both input switches (if you have any with two.)
on/off button on the control panel should work for the dimmer bulb.
slider control is not yet implemented.

...my current issue is that, although I now have the Shelly Dimmer2 device, I don't have any dimmable bulbs! Everything I have is LED, and they're either non-dimmable or smart devices anyway. In particular, I can't tell whether the power and Watts parameters work correctly for the dimmer.
So I'd appreciate a listing of any bugs that you find, and I'll continue to work on the slider control.
Incidentally, I've update to the latest firmware for this device: 20210909-150154/v1.11.4-DNSfix-ge6b2f6d since it came with a very old version that didn't even publish the model number. It seems to work fine, but I've not updated any other of my devices.

@akbooer thank you for the effort, I installed v21.11.2 and have tested this a bit.

For a start I have my switch connected to "sw 1". It is a single button switch, defined as a "one button mode" in the Shelly GUI.
"sw 1" seems to report as "light/0" in the Mqtt message.

It does not work fully in OpenLuup yet, below I list what I have found.

Turning on/off with the physical switch:

• The status in AltUI does change when turning the light on and off.

• When I turn the light "off" with the physical switch I have:
  light/0:
  off
  light/0/status: {"ison":false,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}

• When I turn the light "on" with the physical switch (at 80%) I have:
  light/0:
  on
  light/0/status:
  {"ison":true,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}

Turning the light on/off in AltUI:

• The light does not turn on/off when I turn it on/off in AltUI.

• When I turn it "on" in AltUI I have:
  light/0:
  off
  light/0/status:
  {"ison":false,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}
  relay/0/command:
  on

• When I turn it "off" in AltUI I have:
  light/0:
  off
  light/0/status:
  {"ison":false,"source":"input","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}
  relay/0/command:
  off

When I turn it "on" in AltUI it looks like this:

When I turn on the light with the physical switch it looks like this:

In Mqtt Explorer I have the following:
Light on (i.e. turned on with the physical switch):

Light off (i.e. turned off with the physical switch):

Turning on in AltUI (but light off):

Turning off in AltUI (light still off):

The "relay/0/command" command that is sent from AltUI does in other words not to give any effect on the Shelly device. In fact with a fresh Mqtt Explorer session it only emerges when turning on/off in AltUI.

Hopefully this gives some hints to what is wrong. Let me know if you need more information.

@akbooer said in openLuup: Shelly Bridge plugin:

...my current issue is that, although I now have the Shelly Dimmer2 device, I don't have any dimmable bulbs! Everything I have is LED, and they're either non-dimmable or smart devices anyway. In particular, I can't tell whether the power and Watts parameters work correctly for the dimmer.

Dimmable LED lights are a bit tricky still. Some of them work and some of then do not work very well. It can be a bit of a pain to find good ones. The upside is that the Shelly dimmer can be changed from trailing and leading edge dimming (under "Calibration"). This should hopefully mean that it can be a little bit better to adapt to different lights.

@akbooer said in openLuup: Shelly Bridge plugin:

Incidentally, I've update to the latest firmware for this device: 20210909-150154/v1.11.4-DNSfix-ge6b2f6d since it came with a very old version that didn't even publish the model number. It seems to work fine, but I've not updated any other of my devices.

Excellent news that the latest FW seems to work, I will test it later on one of my devices.