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.

Like @Crille I have an electrical meter with a P1 data port. I use a DIY ESP8266 reader that I described some time ago in this thread. Since writing my post I have changed the software on the ESP, the version I am using now publishes the meter data approx every 10s as a json.

A good wifi solution for the whole house if lacking a dataport is to use a Shelly 3EM. It is a three clamp meter that can measure all three incoming phases, assuming you have that. I have a few of these for measuring both single and multiple phase consumers, e.g. a two-phase water heater. It reports both energy, power, voltage and current per phase.
The only downside I can see is that the clamps are a bit big, so some space is required to get them in place around the incoming power lines.

So I thought I would report back on the restore of openLuup onto my new server.

What I did was roughly:

• set up a fresh install of openLuup on my new server
• stop the old and new server with
  http://192.168.1.xxx:3480/data_request?id=exit
• copy all the content from the folders "files" and "icons" from the old server to the new server (this I had to do with sudo rights in the Terminal)
• copy the latest backup file to the backup foder on the new server
• run the reload openLuup script from the cmh-ludl folder
  ./openLuup_reload backup/backup.openLuup-nnnn.lzap
• restart the server

After this the new server contained all the items from the old installation. Most things has worked, but some things did not.

I had to reinstall the Z-way plugin (plugins->update now button) to get it working, the login fields did not exist (see above) until I did that. After the reinstall I could log in and get it to work.
I also had to reinstall Reactor and the Telegram plugins (plugins->update now button).
Reactor said the database was old and the update button was not there so it could not be updated.
Telegram did not work but everything looked as it should. After the update it worked.
The only remaining oddity from this error is that I now have a Reactor sensor that I cannot remove. It crashed during editing it before I realised that the plugin did not fully work (it is now empty when I open it, so no delete button).
I recreated the logic in a new sensor and disabled the old one.
Any advice on how I can remove the failed sensor would be appreciated.

Yesterday I discovered that my Remotec ZRC90 remotes did not work. The sl_CentralScene did not update when pressing the buttons on the remote. Based on the advice in this thread I reinstalled the development version of the Z-way plugin from the App Store and then it worked. Strange problem, unclear what could be the reason for it.

So a few quirks here and there, it seems as if some data does not survive the restore, unclear why.

@akbooer is it better to do a reinstall from App Store when restoring a backup of from of from Plugins->update now button? Or should it not matter?

As a small side note I also reinstaller Grafana onto the new server. I found a useful tip that it is possible to copy the grafana.db file from the old server to move all of the configuration. This worked perfectly at least on my 8.1.1 installation. The only issue is to make sure to have the same version Grafana on the new server as on the old. This is is easy to do with the help of their webpage.

@catmanv2 MSR is definitely on the list of things to setup and try. It seems really nice and a natural step forward from Reactor.

@catmanv2 yes it can quickly become tricky to have back-ups of everything. I have no clear strategy but some bits-and-pieces that I use.

For the Zway server that is running on a separate Pi I make a complete image with Win32 Disk Imager when I update the server. I run it on a 2.5" ssd, so I have two. That way I can revert back if it crashes hopefully.

For openLuup I do manual backups (Table Controllers->Backup Controller) before changing things. I keep them on another PC for safe keeping. A fresh install and copying the files and icon folders before running the reload script seems to work ok.

Now that I look at migrating to Proxmox I will test another strategy. In Proxmox it is super easy to make a complete copy of the VM. This can then be deployed in a few minutes, no need to set everything up from scratch again. My idea is to use this as a fall back also in combination with openLuup backups. Also to use it when testing things on a temporary VM before updating the live VM.

I have not moved over to MSR yet so thte Reactor logic is part of the openLuup backups.

The plan is also to run my Home Assistant on the Proxmox server to be able to have a live server and a test server in parallel.

@akbooer that seems to have worked quite nicely when checking quickly on all the devices, thank once more for the quick response.

One thing that does not work is the connection to the Z-Way server. The devices do not update when changing them either in the new openLuup or in the Zway UI.
I suspect I need to login again to connect the bridge with the server.
If I remember it correctly I should do that in the Console under "actions" for the Z-Way bridge. However it is empty there:

Any ideas on that one?

Edit: I have version 21.1.19 of the Z-Way bridge. On my old installation the login fields are there under "actions".

Edit 2: I updated the Z-way plugin. This gave me a second plugin, also the username/passwd dialogues reappeared on the old bridge.
After having deleted the new bridge, logged in into the old one and restarted openLuup it seems to work. I will see if anything looks strange.

Next question.

When restoring from a backup file from another OpenLuup what is the best approach to get everything up and running on the new openLuup installation with icons, plugins etc?

Should I manually copy e.g. icons and something else before restoring. Also do I have to install the plugins again?

//ArcherS

That did the trick!

Alpine and Docker, need to look at that also later on.

Thank's @CatmanV2 and @akbooer for your swift help!

Hi,

I am trying to install openLuup on a new Debian 11 server. It is a clean install Debian 11 running as a VM on Proxmox.

I have installed lua 5.1, lua-socket, lua-filesystem and lua-sec.

When installing openLuup with "# lua5.1 openLuup_install.lua" I get the following response:

debian-pve:~/cmh-ludl$ lua5.1 openLuup_install.lua
openLuup_install   2019.02.15   @akbooer
getting openLuup version tar file from GitHub branch master...
un-zipping download files...
getting dkjson.lua...
creating required files and folders
initialising...
downloading and installing AltUI...
sh: 1: curl: not found
lua5.1: ./openLuup/L_AltAppStore.lua:567: attempt to call upvalue 'next_file' (a nil value)
stack traceback:
	./openLuup/L_AltAppStore.lua:567: in function 'update_plugin_job'
	openLuup/init.lua:254: in main chunk
	[C]: ?
openLuup downloaded, installed, and running...
visit http://192.168.1.210:3480 to start using the system
olsson@debian-pve:~/cmh-ludl$ Sat Aug 27 13:35:31 2022	device 2 '    openLuup' requesting reload

When I try to go to the url "http://192.168.1.210:3480" I get the following response:

No handler for data_request?id=lr_ALTUI_Handler

In other words it seems as if there is a problem starting AltUI.

If I instead go to the Console (http://192.168.1.210:3480/console) openLuup is up and running.

The startup_log in the Console reads:

2022-08-27 13:35:31.488   :: openLuup STARTUP :: /home/olsson/cmh-ludl
2022-08-27 13:35:31.488   openLuup.init::        version 2021.06.14  @akbooer
2022-08-27 13:35:31.489   openLuup.scheduler::   version 2021.03.19  @akbooer
2022-08-27 13:35:31.510   openLuup.io::          version 2021.03.27  @akbooer
2022-08-27 13:35:31.510   openLuup.mqtt::        version 2021.06.08  @akbooer
2022-08-27 13:35:31.511   openLuup.wsapi::       version 2019.08.12  @akbooer
2022-08-27 13:35:31.511   openLuup.servlet::     version 2021.04.30  @akbooer
2022-08-27 13:35:31.511   openLuup.client::      version 2019.10.14  @akbooer
2022-08-27 13:35:31.512   openLuup.server::      version 2020.03.26  @akbooer
2022-08-27 13:35:31.518   openLuup.scenes::      version 2021.06.02  @akbooer
2022-08-27 13:35:31.520   openLuup.chdev::       version 2021.05.04  @akbooer
2022-08-27 13:35:31.521   openLuup.userdata::    version 2021.04.30  @akbooer
2022-08-27 13:35:31.521   openLuup.requests::    version 2021.02.20  @akbooer
2022-08-27 13:35:31.521   openLuup.gateway::     version 2021.05.08  @akbooer
2022-08-27 13:35:31.522   openLuup.smtp::        version 2018.04.12  @akbooer
2022-08-27 13:35:31.523   openLuup.historian::   version 2021.06.12  @akbooer
2022-08-27 13:35:31.523   openLuup.luup::        version 2021.05.14  @akbooer
2022-08-27 13:35:31.524   openLuup.pop3::        version 2018.04.23  @akbooer
2022-08-27 13:35:31.524   openLuup.compression:: version 2016.06.30  @akbooer
2022-08-27 13:35:31.524   openLuup.timers::      version 2021.05.23  @akbooer
2022-08-27 13:35:31.524   openLuup.logs::        version 2018.03.25  @akbooer
2022-08-27 13:35:31.524   openLuup.json::        version 2021.05.01  @akbooer
2022-08-27 13:35:31.524   luup.create_device:: [1] D_ZWaveNetwork.xml /  /    ()

2022-08-27 13:35:31.525   openLuup.chdev:: ERROR: unable to read XML file I_ZWave.xml

2022-08-27 13:35:31.530   luup.create_device:: [2] D_openLuup.xml / I_openLuup.xml / D_openLuup.json   (openLuup)
2022-08-27 13:35:31.530   openLuup.init:: loading configuration user_data.json
2022-08-27 13:35:31.530   openLuup.userdata:: loading user_data json...
2022-08-27 13:35:31.532   luup.variable_set:: 2.openLuup.HouseMode was: EMPTY now: 1 #hooks:0
2022-08-27 13:35:31.532   openLuup.userdata:: loading rooms...
2022-08-27 13:35:31.532   openLuup.userdata:: ...room loading completed
2022-08-27 13:35:31.532   openLuup.userdata:: loading devices...
2022-08-27 13:35:31.532   luup.create_device:: [1] D_ZWaveNetwork.xml /  /    ()

2022-08-27 13:35:31.532   openLuup.chdev:: ERROR: unable to read XML file I_ZWave.xml

2022-08-27 13:35:31.534   luup.create_device:: [3] D_AltAppStore.xml / I_AltAppStore.xml / D_AltAppStore.json   (urn:schemas-upnp-org:device:AltAppStore:1)
2022-08-27 13:35:31.534   openLuup.userdata:: loading scenes...
2022-08-27 13:35:31.534   openLuup.userdata:: number of scenes = 0
2022-08-27 13:35:31.534   openLuup.userdata:: ...scene loading completed
2022-08-27 13:35:31.534   openLuup.userdata:: loading installed plugin info...
2022-08-27 13:35:31.534   openLuup.userdata:: [openLuup] openLuup (21.7.25)
2022-08-27 13:35:31.534   openLuup.userdata:: [AltAppStore] Alternate App Store (20.3.30)
2022-08-27 13:35:31.534   openLuup.userdata:: [VeraBridge] VeraBridge (not.installed)
2022-08-27 13:35:31.534   openLuup.userdata:: [8246] Alternate UI (not.installed)
2022-08-27 13:35:31.534   openLuup.userdata:: [Z-Way] Z-Way (not.installed)
2022-08-27 13:35:31.534   openLuup.userdata:: [Arduino] MySensors (not.installed)
2022-08-27 13:35:31.534   openLuup.userdata:: ...user_data loading completed
2022-08-27 13:35:31.534   openLuup.init:: running _openLuup_STARTUP_
2022-08-27 13:35:31.534   luup_log:0: startup code completed
2022-08-27 13:35:31.534   openLuup.init:: init phase completed
2022-08-27 13:35:31.534   :: openLuup LOG ROTATION :: (runtime 0.0 days) 

Any ideas on what could be wrong and why AltUI does not work?

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!