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

@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!

@akbooer I am on 7.3.1 and what I have done is to add links on the top of the pages to navigate between them.
The link buttons work pretty well also on an iPad or even on the phone.

//ArcherS

@akbooer Yes a scene or a Reactor could of course work. This is what I did on the Vera in a Reactor and it worked quite ok. I will give it a go again in OpenLuup. The on/off switches on the controller in the GUI do not really matter that much I think.

Regards
//ArcherS

I included a ZRC90 remote to Z-way. The inclusion was without problems, and in Z-way you can see what button is pressed.

In OpenLuup I get the same variables as Catman has listed above. I tested and the two variables "zway_61-0-91-DS" and "zway_61-0-91-DS_LastUpdate" on the remote device are updated on key presses.

Depending on what you press "zway_61-0-91-DS" get the following values:
Btn 1 single press: 10
Btn 2 single press: 20
...
Btn 8 single press: 80

Btn 1 double press: 13
Btn 2 double press: 23
...
Btn 8 double press: 83

Btn 1 press&hold: 11
Btn 2 press&hold: 21
...
Btn 8 press&hold: 81

Each time a button is pressed zway_61-0-91-DS_LastUpdate is also updated with a new time.

So far so good, the above two parameters gives the possibility to capture the various key presses on the ZRC90.

What does not work is that I get the same problem as I did for the Zwave.me wall controller, i.e. that the two variable are not updated in Reactor on key presses.
@akbooer is this something that can be fixed?

I am running OL 20.7.4b and Z-way plugin 20.5.12.
(The key presses on the Zwave.me wall controller are still working.)

//ArcherS

One solution that I can think of is to use MySensors. https://www.mysensors.org/
This is a DIY community platform for making sensors etc. It is supported by Vera and OpenLuup, @akbooer is using it if I am not wrong.

I found someone that had made a water pressure sensor that you perhaps could have a look at for inspiration: https://forum.mysensors.org/topic/8731/water-pressure-sensor/1?_=1590472756396&lang=en-US

In short with MySensors you set up a gateway and then the sensors you want. Each node is an Arduino or similar. I used an USB connected gateway with my Vera, but an Ethernet connected gateway is needed for OpenLuup.

I set it up a number of years ago on my VeraLite and it actually worked really well. I used it mainly for simple temperature sensors. I stopped using it because of that each time the Vera rebooted the gateway was lost, and I had to re-discover it on the Vera USB port. Quite a bit of hazzle since the Vera had a tendency to reboot quite a lot.

If I get some time I may have a go at restarting MySensors now that I am using OpenLuup since it would be a good way to add dirt-cheap sensors to the system.

@akbooer sorry, no I do not have a complete list of the variables created in Vera. I forgot to check that before excluding.

By the looks of the controller I am quite sure it is the one in this old Vesternet guide APNT-44

In fact if I remember it correctly that guide is what I used on my VeraLite on UI5 many years ago.

On the UI7 Vera I however used "sl_SceneActivated".
I also think that "LastSceneTime" was present on it. (These represent the "zway_Remote_16-0-1-B" and "zway_Remote_16-0-1-B_LastUpdate" at present I assume.)

You are correct that all I would need are those two variables as triggers, because then I can use the on/off as one trigger and the time as a trigger as well. I think I may need the time to capture e.g. if you press the "off" button and the controller already was "off". I tested this and the time is updated.

Thank you very much for your time and effort.

//ArcherS

I updated to v20.7.12 and it works partially!

"LastSceneTime" is updated every time you press a key, so that one works.

"sl_CentralSceneUpdates" however stays "null" all the time.

On the ZRC90 that I still have on the Vera there is a variable called "sl_CentralScene" but no variable called "sl_CentralSceneUpdates". I do not know if this could be the reason.

As a side note the variables "zway_61-0-91-DS" and "zway_61-0-91-DS_LastUpdate" are now updated instantly in Reactor.
So a functional workaround could be to use the "zway_61-0-91-DS" and "LastSceneTime" variables for capturing keys pressed in e.g. Reactor. I did a quick test and it seems to work.

Edit: I have the TZ67 not the TZ68

I have two TKB devices also (TZ67 Dimmers, not the switch).

My dimmers are both also on version 4.54.00. They are stuck on 88% interview in Z-way, NodeNaming never get interviewed.

Not exactly the same problem as for @powisquare, they do change state in the gui when triggered by a scene.
They do however not report back state when you press the button on the device.
They do not have any association either, no lifeline and not possible to add any associations. So I would say that the old FW could very well be the reason even though I have the dimmers.

I have used them in places where you never press the button on the device, then they are useful, but mostly I do not use them.

@therealdb yep, it is still working, still only one test device receiving data.
I get the same error related to the http issue from time to time as shown in the log above, but it recovers and continue updating the device.

@therealdb that sounds reassuring, thanks!

As a side note to anyone venturing into the world of mqtt I found Mqtt Explorer which seems to be a pretty nice tool for looking at messages, topics etc.
It can even create graphs for values to track them over time.

@therealdb I have now had the updated Mqtt Bridge running continuously for little more than 25 hours. So far it is still alive and kicking.

The log file is now working I get entries in the log, which I did not get before. This makes it easier to see what is happening of course.
So when the bridge starts I get:

2021-01-30 11:24:16.055 +01:00 [INF] [MQTTServer] Broker is starting v 0.31.210130 on port 1883...
2021-01-30 11:28:40.877 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 24.5
2021-01-30 11:33:40.770 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 24.9
etc...

At times I get the following error, I assume it is related to the http issue:

2021-01-31 11:38:40.852 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 25.5
2021-01-31 11:38:50.854 +01:00 [ERR] [LuupWrapper] RunCommandAsync: http://127.0.0.1:3480/data_request?id=variableset&output_format=json&DeviceNum=216&serviceId=urn:upnp-org:serviceId:TemperatureSensor1&Variable=CurrentTemperature&Value=25.5&RunAsync=1
System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 10 seconds elapsing.
 ---> System.TimeoutException: The operation was canceled.
 ---> System.Threading.Tasks.TaskCanceledException: The operation was canceled.
 ---> System.IO.IOException: Unable to read data from the transport connection: Operation canceled.
 ---> System.Net.Sockets.SocketException (125): Operation canceled
   --- End of inner exception stack trace ---
   at void System.Net.Sockets.Socket+AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at int System.Net.Sockets.Socket+AwaitableSocketAsyncEventArgs.GetResult(short token)
   at async ValueTask System.Net.Http.HttpConnection.FillAsync(bool async)
   at async ValueTask<ArraySegment<byte>> System.Net.Http.HttpConnection.ReadNextResponseHeaderLineAsync(bool async, bool foldedHeadersAllowed)
   at async Task<HttpResponseMessage> System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, bool async, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at async Task<HttpResponseMessage> System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, bool async, CancellationToken cancellationToken)
   at async ValueTask<HttpResponseMessage> System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, bool async, bool doRequestAuth, CancellationToken cancellationToken)
   at async ValueTask<HttpResponseMessage> System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, bool async, CancellationToken cancellationToken)
   at async Task<HttpResponseMessage> Microsoft.Extensions.Http.Logging.LoggingHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at async Task<TResult> Polly.Retry.AsyncRetryEngine.ImplementationAsync<TResult>(Func<Context, CancellationToken, Task<TResult>> action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates<TResult> shouldRetryResultPredicates, Func<DelegateResult<TResult>, TimeSpan, int, Context, Task> onRetryAsync, int permittedRetryCount, IEnumerable<TimeSpan> sleepDurationsEnumerable, Func<int, DelegateResult<TResult>, Context, TimeSpan> sleepDurationProvider, bool continueOnCapturedContext)
   at async Task<TResult> Polly.AsyncPolicy<TResult>.ExecuteAsync(Func<Context, CancellationToken, Task<TResult>> action, Context context, CancellationToken cancellationToken, bool continueOnCapturedContext)
   at async Task<HttpResponseMessage> Microsoft.Extensions.Http.PolicyHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at async Task<TResult> Polly.Bulkhead.AsyncBulkheadEngine.ImplementationAsync<TResult>(Func<Context, CancellationToken, Task<TResult>> action, Context context, Func<Context, Task> onBulkheadRejectedAsync, SemaphoreSlim maxParallelizationSemaphore, SemaphoreSlim maxQueuedActionsSemaphore, CancellationToken cancellationToken, bool continueOnCapturedContext)
   at async Task<TResult> Polly.AsyncPolicy<TResult>.ExecuteAsync(Func<Context, CancellationToken, Task<TResult>> action, Context context, CancellationToken cancellationToken, bool continueOnCapturedContext)
   at async Task<HttpResponseMessage> Microsoft.Extensions.Http.PolicyHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at async Task<HttpResponseMessage> Microsoft.Extensions.Http.Logging.LoggingScopeHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at async ValueTask<HttpResponseMessage> System.Net.Http.HttpClient.SendAsyncCore(HttpRequestMessage request, HttpCompletionOption completionOption, bool async, bool emitTelemetryStartStop, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   --- End of inner exception stack trace ---
   at async ValueTask<HttpResponseMessage> System.Net.Http.HttpClient.SendAsyncCore(HttpRequestMessage request, HttpCompletionOption completionOption, bool async, bool emitTelemetryStartStop, CancellationToken cancellationToken)
   at async Task<string> System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at async Task Luup.MqttBridge.Services.LuupWrapper.RunCommandAsync(int deviceID, string action, string actionCommand, string commandParameter, string command, string serviceID, string value)
2021-01-31 11:43:40.851 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 25.5
2021-01-31 11:48:40.836 +01:00 [INF] [MQTTServer] Updating #216 - urn:upnp-org:serviceId:TemperatureSensor1 / CurrentTemperature - 25.6
etc...

After the above error it goes back to reporting updates.
The error comes quite random, at times once every approx 20-30 minutes, and at times it can be a few hours between them.

So far I have only one test device in OpenLuup getting values from the bridge, I do not know how adding some 50+ topics would affect the overall load and stability.

Edit: It could be worth mentioning that I today have some 50 devices in OpenLuup that are getting their values over http; some SiteSensors a bunch of virtual sensors getting data from Tasmota/Shelly devices etc. In other words there is a bit of activity already going on through the http interface today. Moving most of them to Mqtt would perhaps not increase the load at all, who knows.

Looking promising, thanks for the effort so far with the bridge!

@therealdb new version built and started, I will report back how it goes.

@therealdb I was able to build the previous versions, so I can try the new version if you push it.

@therealdb yep, I am on OpenLuup.
I tested and the old version also crashes in the same way after 30-60 minutes.

//ArcherS

@therealdb I noticed that the bridge had gone down over night. I restarted it and got the below error message after approx 10-15 minutes when it went down again. It ran for longer yesterday, maybe 1-2 hours before crashing.

I now started the old version (that works, it was of course my error on the Client in the Tasmota that was the problem), just to see if it also will go down.

//ArcherS

[08:55:53 INF] [MQTTServer] Broker is starting v 0.30.210109 on port 1883...
Unhandled exception. System.Threading.Tasks.TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 10 seconds elapsing.
 ---> System.TimeoutException: The operation was canceled.
 ---> System.Threading.Tasks.TaskCanceledException: The operation was canceled.
 ---> System.IO.IOException: Unable to read data from the transport connection: Operation canceled.
 ---> System.Net.Sockets.SocketException (125): Operation canceled
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Net.Http.HttpConnection.FillAsync(Boolean async)
   at System.Net.Http.HttpConnection.ReadNextResponseHeaderLineAsync(Boolean async, Boolean foldedHeadersAllowed)
   at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at Microsoft.Extensions.Http.Logging.LoggingHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at Polly.Retry.AsyncRetryEngine.ImplementationAsync[TResult](Func`3 action, Context context, CancellationToken cancellationToken, ExceptionPredicates shouldRetryExceptionPredicates, ResultPredicates`1 shouldRetryResultPredicates, Func`5 onRetryAsync, Int32 permittedRetryCount, IEnumerable`1 sleepDurationsEnumerable, Func`4 sleepDurationProvider, Boolean continueOnCapturedContext)
   at Polly.AsyncPolicy`1.ExecuteAsync(Func`3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext)
   at Microsoft.Extensions.Http.PolicyHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at Polly.Bulkhead.AsyncBulkheadEngine.ImplementationAsync[TResult](Func`3 action, Context context, Func`2 onBulkheadRejectedAsync, SemaphoreSlim maxParallelizationSemaphore, SemaphoreSlim maxQueuedActionsSemaphore, CancellationToken cancellationToken, Boolean continueOnCapturedContext)
   at Polly.AsyncPolicy`1.ExecuteAsync(Func`3 action, Context context, CancellationToken cancellationToken, Boolean continueOnCapturedContext)
   at Microsoft.Extensions.Http.PolicyHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at Microsoft.Extensions.Http.Logging.LoggingScopeHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.SendAsyncCore(HttpRequestMessage request, HttpCompletionOption completionOption, Boolean async, Boolean emitTelemetryStartStop, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpClient.SendAsyncCore(HttpRequestMessage request, HttpCompletionOption completionOption, Boolean async, Boolean emitTelemetryStartStop, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at Luup.MqttBridge.Services.LuupWrapper.RunCommandAsync(Int32 deviceID, String action, String actionCommand, String commandParameter, String command, String serviceID, String value)
   at Luup.MqttBridge.Services.LuupWrapper.UpdateVariablesAsync(Int32 deviceID, String serviceID, String variableName, String value)
   at Luup.MqttBridge.Services.Mqtt.MQTTServer.ProcessMessageAsync(MqttDevice device, MqttApplicationMessage applicationMessage)
   at Luup.MqttBridge.Services.Mqtt.MQTTServer.<>c__DisplayClass9_0.<<StartAsync>b__3>d.MoveNext()
--- End of stack trace from previous location ---
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__140_1(Object state)
   at System.Threading.QueueUserWorkItemCallbackDefaultContext.Execute()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
/home/user/mqttbridge/LuupMqttBridge.sh: line 1: 20380 Aborted                 (core dumped) ./Luup.MqttBridge

So I did some more testing and found out that I had still "DVES_%06X" as client in the Tasmota device...
I am sure I had tripple checked everything, stupid...

So I changed this to what it should be and now I get it to work , i.e. the device in OpenLuup gets the temp value. Success!

However the log does still not give more that the starting message for some reason.
Any ideas on this? Btw I still have this in the appsettings, not sure if that could be related:?

/* remove comment when you're OK with less logs
	"Serilog": {
		"MinimumLevel": {
			"Default": "Information",
			"Override": {
				"Microsoft": "Fatal",
				"System": "Fatal"
			}
		}
	}
	*/

I will do some more testing later on and see.
Thanks for the assistance!

//ArcherS

@therealdb thanks for the build!

When using your latest build the Luup.MqttBridge file for some reason is a "shared library (application/x-sharedlib)" and not as when building from the older version "executable (application/x-executable)" despite having set permissions.
Really strange, I managed to get around this by creating a .sh file containing "./Luup.MqttBridge" and running this.
Over first hurdle...

However when I launch the new built file I still only get this in the log file:

[19:17:23 INF] [MQTTServer] Broker is starting v 0.30.210109 on port 1883...

It is as if it hangs while trying to start/starting.

In the Tasmota console it says connected so the user/passwd seems ok:

19:17:21 MQT: Connected

So obviously not quite there yet.
Any ideas on what the pronlem could be?

//ArcherS