the residential (standalone) configuration is already supported in OH3 snapshot (we are re-defining things names), and it will be surely included in 3.1.
Have you tested the LN4890 with the openwebnet binding before ? does it work? I do not recall it can be used as a OpenWebNet gateway.
If yes, you can setup the RaPi with OH3 and the latest 3.1 snapshot and connect it to the LN4890 + NT4695 + room thermostats. Then we can involve you in some testing.
Let me know.
Have you tested the LN4890 with the openwebnet binding before ? does it work? I do not recall it can be used as a OpenWebNet gateway.
Yes, I used it as OH gateway for two years before installing MHS1. Just now it is still used as gateway for AUX command coming from domoticz to the 3486 alarm.
If yes, you can setup the RaPi with OH3 and the latest 3.1 snapshot and connect it to the LN4890 + NT4695 + room thermostats. Then we can involve you in some testing.
Sure I can connect NT4695 to the bus, configuring it via MyHomeSuite and control it by LN4890. What is hard to do (i think but I’m not sure) is manage the room thermostats both via MHS1 and LN4890 without loosing actual thermo controls during these hot days: they are controlling the refreshing system. I’ll try in few days and I’ll report here if this setup is acceptable and running.
I’ll update also 3.0 to latest snapshot to see how standalone thermostats work, TY for your great effort!
hello, I have 4 LN4691 with gateway F455 and I am ready to test new binding. I would like to inform about a problem still present from old version binding. it seems the bus doesn’t respond after add LN4691, it’s like any device (also shutters) respond after many seconds from commands input. To stop this issue it is necessary to change manually set point temperature on every thermostat and to push up or down button on shutters. After this procedure the bus responds in real time. Hope can help. Roberto
What do you mean with “does not respond for a while”?
The discovery only looks for devices connected to the bus without reading the state, you should see “waiting for status update” label in OH dashboard with a yellow background. This does not means the device can’t be used, if you change a parameter from app/physical device it will be updated (green background) , if you don’t change anything you have to wait a device update over the bus (which may take some time).
Is this your case?
Hello Andrera, maybe I made a mistake in my previous post. I try to explain better. I was waiting for a long time the official openwebnet binding for openhab 3 able to mange standalone thermostats and I realized only yesterday about the existence of alpha version with these features. (I am not a developer so I don’t pretend that opensource community had to run to develop that, I thank you all you guys for your precious work) That said, the issue I was talking about it’s on openhab 2.5 not on version3. I am ready to test the oh3 alpha version. The second mistake was about Massimo question, he asks if someone can test a 4 zone thermostat but I have 4 standalone thermostats. Sorry for my confusion. To answer on your question (that was an issue on 2.5), the discovery works fine, the devices are correctly found and add on control panel but as I said to let everything working well I have to manually change state on every device, after that procedure everything respond in real time. Without that procedure the bus seems busy and commands have a 20-30 seconds delay. I imagine no one would have to spend time on 2.5 bugs and of course I am not asking that ) Maybe my configuration is not so standard as well, because I have a linux machine with a lots of containers, “openhab” is developed on docker and it communicates with a “nodered” container for programming reason (I suggest everyone to play with nodered opensource, there exists any kind of module, also for openhab and google home and it permit to configure vocal commands on every openhab things).
Hi, I have a flooding issue as well on oh2.5. After binding implementation and added things like thermostat and shutters, Commands have a long delay, devices respond after half minute, I resolved by manually changing state on every thermostat and shutter (try to change set point temperature or open-close shutter with your finger on physical device, not by software) This is not the definitive solution but maybe can help developer as well as the log to understand better this strange behavior
Sorry to say but OH2.x is no longer supported, all development effort is focused only on OH3.
@Roberto please note that Google Home / Alexa is supported by OH3 without needs of additional tools: I’m controlling my plant (light and thermoregulation) from Google Assistant without issues (I can read and set zone temp, turn on/off lights…)
how did you configure it? It should not work with discovery.
I have everything configured with text files. I keep both gateway configured as mhs1 but one is commented out, so if the first fails, I restart OH with the second one activated, and all items have the same name with both gateways. So
// MHS1
Bridge openwebnet:bus_gateway:mhs1 [ host="192.168.1.40", passwd="*******" ] {
//
// Touch 3.5 LN4890
// Bridge openwebnet:bus_gateway:mhs1 [ host="192.168.1.50", passwd="*******" ] {
ok @fmalfatto if you set the log at DEBUG level and start a new discovery and copy here the log where the LN4890 is found (just search for “LN4890”, I will add it to the offical supported gateways so it can get discovered automatically.
I found the problem thanks to your and @bastler 's DEBUG logs.
In fact after a OH restart lighs/shutters status is requested multiple times (because the gateway takes too long to return status for all lights), and with systems with many lights /shutters this creates a lot of messages on the BUS.
I created an issue to track the correction of this problem
That’s a great new Massimo, many thanks for your time and effort, really appreciated. Can I donate some?
I wonder if that was the same problem with the old binding crashing the mh102
No, the refresh status after reboot was added last month and only to OH3
Yes, you can donate just to say thanks or, like others did already, to express your interest to new features/next steps for the openwebnet part and support them.
See here: openwebnet4j | A Java library for the Open Web Net protocol
Another way to also attract new developers is to open a new request through an issue here, and then put a bounty on it here: https://www.bountysource.com/teams/openhab.
I never used this Bountysource so I do not know how it works in practice.
ok @fmalfatto if you set the log at DEBUG level and start a new discovery and copy here the log where the LN4890 is found (just search for “
LN4890”, I will add it to the offical supported gateways so it can get discovered automatically.
Startup without defining the LN4890 in the things file:
+=== UPnP =========================================
| ID.UDN : uuid:pnp-touchscreen-4_0-00:03:50:8F:24:74
| ID.DESC URL : http://192.168.1.50:49152/
| ID.MAX AGE : 500
| --------------
| MANUFACTURER : BTicino S.p.A. (http://www.bticino.it)
| MODEL : LN4890 | Touch Screen Color | 4.0 (http://www.bticino.it)
| FRIENDLY NAME: Touch salone
| SERIAL # : 00:03:50:8F:24:74
| BASE URL : null
| UPC : null
+==================================================
2021-06-21 16:53:38.237 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - |- LN4890 (BTicino S.p.A.)
2021-06-21 16:53:38.245 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found BTicino device: not a OpenWebNet gateway or is not supported (UDN=pnp-touchscreen-4_0-00:03:50:8F:24:74)
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
After having defined this way
// Touch 3.5 LN4890
Bridge openwebnet:bus_gateway:LN4890 [ host="192.168.1.50", passwd="*******" ] {
}
Restarted OH :
2021-06-21 17:02:36.045 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - Initializing BUS gateway
2021-06-21 17:02:36.058 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - Creating new BUS gateway with config properties: 192.168.1.50:20000, pwd=*********, discoveryByActivation=false
2021-06-21 17:02:36.111 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - Trying to connect gateway BUS_192.168.1.50:20000...
2021-06-21 17:02:36.435 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - bridge openwebnet:bus_gateway:LN4890 initialization completed
2021-06-21 17:02:36.440 [INFO ] [bnet.handler.OpenWebNetBridgeHandler] - ---- CONNECTED to BUS gateway bridge 'openwebnet:bus_gateway:LN4890' (192.168.1.50:20000)
2021-06-21 17:02:36.446 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - updated property gw serialNumber: 00:03:50:8F:24:74
2021-06-21 17:02:36.450 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - updated property gw firmware version: 4.0.15
2021-06-21 17:02:36.462 [INFO ] [bnet.handler.OpenWebNetBridgeHandler] - properties updated for bridge 'openwebnet:bus_gateway:LN4890'
2021-06-21 17:02:36.975 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - Refreshing all devices for bridge openwebnet:bus_gateway:LN4890
I tested it, but I find only temperature and setpointTemperature. Missing heatingCoolingMode, activeMode, heating, cooling …
Did these items change name?
yes, some did, please look here at documentation to see the correct names:
Thank you very much, I missed that post!
Here is a jar which should solve the “flooding on reboot issue” (it does not contain Thermo part yet, as it’s based on 3.1M5). @Rob-VF , @bastler, and @aconte80: if you have time to test it , let me know if it solves the problem.
org.openhab.binding.openwebnet-3.1.0-SNAPSHOT_flooding.jar.pdf (184.6 KB)