good choice 
i installed the 3.5.29, works but i cannot see any improovement. also the dimmer10 is still only available max a=9, pl=9 
I have the same problem.
The developer said to change manually the addresses, but I havent been able to.
So I end up with ports not being able to use 
I really don’t see what problems could cause to let the user use those addresses and if there are problems it’s a user problem to correct.
In MyHome and bTicono HomeServer they are well accepted!
@massi: any chance you could reenable those addresses?
Indeed @bastler,
What I referred to earlier was the Where address at A=0 PL=X, where X is anything between 0 and 9. Thus, now with 4.2.x everything with where with A=0 ain’t working.
I get that now there is “documentation” that says not to use A=0 per your summary.
Thinking out loud on the following:
- I have been using and upgrading with A=0 since 2018 and passed through the Openhabs from the 2. x to the 3. x to now the 4. x and finally the stable 4.1.1 with no issues to mention
- The Myhomeserver1 setup is dynamic in that the user does not specify an address similar to the MH202. Before that, we used the MyHome_Up under installer to set it up, and you then scanned it. Now we have Project+, which does a similar job; again, you do not have access to configure or access these addresses, with these addresses being set by the HomeServer1 server itself
- If the documentation says no A=0, then the MyServerHome1 server itself (based on the above) should change and update. Correct?
- Practically, I cannot avoid A=0. These are coming from MyHomeServer1, and I cannot overwrite them, and I have no way to force the setup in Openhab. Nine lights and one Automation are linked under those addresses. The funny part is that these are the most items I use (irony, among other things); it is like being done on purpose to spite me
I believe this whole no A=0 needs to be revised to accommodate whatever constraint has been set and implemented now, factor in the case for MyHomeServer1, and, at worst, provide a workaround we can address and apply to get these working again.
I am happy to test and help in achieving the desired outcome.
Your thoughts
Thank you
Espresso
1 Like
me too, i had configured all my motion sensors bmse3003 with a=0 (file based) since 2014 already. i also was not aware of the “a=0-problematic” and had a wrong file based config eg [ where="01#4#01" ] (the #4#01 because i use private riser for each floor). i realized sometimes strange delays from sending a command (from a physical switch) until it was executed. often the delay was just a couple of seconds but somtimes it grow up until 1 minute! this was not reproducable, very differnt commands from starting music, controlling garage door, switching lights… that sometimes got executet at once and another time they where delayed.
first i did not mind but It’s been bothering me more and more lately. meanwhile i was thinking about throwing out bticino and switching to knx. but then i set the log level of the binding to debug and there i saw that often when the motion sensors sent a command the connection to the gateway got lost and had to be esablished again. so i came over it and changed adresses away from a=0 - and since then no problem, everything works smooth without delays.
sorry i don’t know, my system is from 2014 and i use a f454 webserver and a mh200n as gateways. my actors are configurable virtually and this i do with the software ‘myhome_suite’ very fast and easy.
puh, ok, if the adresses from your actors are set from myhomeserver then i would suppose they should be set correct. interesting for me, so i think i never can switch to myhomeserver because it would mix all my adresses that i noted in my personal docu and tried to set logically. but if you have problems with auto discovered things, did you check if the where are discovered correct (eg a=0009)? if yes - it should work. if no - you could try if it works with a file based config.
hi, I moved recently to OH 4 with this new binding. since then I’ve been experiencing this problem:
after a few hours all the commands no longer work with this error.
I can solve it by moving the bridge from the MH200N to an old F453 or vice versa
2024-10-20 19:46:28.716 [WARN ] [al.handler.OpenWebNetLightingHandler] - Exception while processing command OFF: CMD is not connected
i use a f454 and a mh200n in two different installations, both without problems. not sure but if you read my post direct over yours, i also had strange problems with lost gateway connections when i used not allowed a/pl adresses. don’t remember the error message and whats definitly different, my gateways could establish the connections from alone, with a delay from less seconds up to a minute.
perhaps also check your adresses, i have no other idea as the gateways should not be the problem.
the question in that using openwebnet for OH 2.x I never encountered this problem.
I have few devices configured for now: i can control them only for few hours, after I cannot interact with them anymore.
As an update, I have had no luck getting MyHomeServer1 with the automatic address allocation to work with the latest Openwebnet plugin.
It is interesting that if I delete all the items in question and then add them via automatic discovery (they are being discovered properly, i.e., read), the communication is not established.
I believe a code change is needed to manage this.
Cheers,
no one can help me?
every few days I encountered this error and I have to reboot openhab.
==> /var/log/openhab/openhab.log <==
2024-11-06 20:33:02.164 [DEBUG] [ernal.handler.OpenWebNetThingHandler] - handleCommand() (command=ON - channel=openwebnet:bus_on_off_switch:MH202_000350012774:33:switch)
2024-11-06 20:33:02.166 [DEBUG] [al.handler.OpenWebNetLightingHandler] - handleSwitchCommand() (command=ON - channel=openwebnet:bus_on_off_switch:MH202_000350012774:33:switch)
2024-11-06 20:33:02.168 [WARN ] [al.handler.OpenWebNetLightingHandler] - Exception while processing command ON: CMD is not connected
in the past I used older version of OpenWebNet binding on OH 2.x for weeks with no errors…
Hi,
Same problem to me:
2024-10-21 06:54:29.155 [WARN ] [nwebnet4j.communication.BUSConnector] - (HS) ... handshake not completed but timeout expired, closing BUS-CMD channel
2024-10-21 06:54:29.156 [WARN ] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## openCommandConnection() returned exception (Could not open BUS-CMD connection to xxx.xxx.xxx.xxx:20000 (IOException: Socket closed)) while opening NEW CMD connection
2024-11-06 06:54:29.157 [WARN ] [al.handler.OpenWebNetLightingHandler] - Excpetion while requesting refresh for light area: IOException while sending frame *#1*1## or reading response: Cannot create NEW CMD connection to send message *#1*1##
2024-11-06 06:54:29.157 [WARN ] [al.handler.OpenWebNetLightingHandler] - Excpetion while requesting refresh for light area: CMD is not connected
I’m using OH 4.3.0.M2 on RPI 5. After that error the SCS bus seems to be overloaded. The physical switch respond with a lot of delay and the scenario, programmed in my MH200N, are no longer performed.
The only solution is restart the Openwebnet binding.
No problem with the old RPI3 with OH 4.1.2.
I think that the RPI5 is too fast with the bus request so my old MH200N crashes.
In this weekend I will try a clean installation of the OH4.3.0.M2 on a RPI3 to confirm this hypothesis.
I’m keeping you informed.
By
Giovanni
Hello,
Is there any update with a fix for the MyHomeServer1 with the OH 4.2.x and above?
Thank you
1 Like
Hi,
I’ve switch to openHAB 4.3.0.RC1.
The error on the BUS no longer occurred after I changed an address with PL=0.
However, the system is unstable. It works correctly for a while (from a minimum of a few hours to a maximum of two days) but then it is necessary to reboot the system or restart the openhab service. The web interface is not accessible and it is not always possible to access via ssh.
No errors are seen in the openHAB log files but using the journalctrl command results in exceptions, which seem to depend on the openwebnet4j library.
The journalctrl output is:
....
dic 15 21:06:33 OpenHAB karaf[891]: Exception in thread "Thread-244" java.lang.NullPointerException: Cannot invoke "Object.hashCode()" because "key" is null
dic 15 21:06:33 OpenHAB karaf[891]: at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
dic 15 21:06:33 OpenHAB karaf[891]: at org.openhab.binding.openwebnet.internal.handler.OpenWebNetBridgeHandler.getRegisteredDevice(OpenWebNetBridgeHandler.java:440)
dic 15 21:06:33 OpenHAB karaf[891]: at org.openhab.binding.openwebnet.internal.handler.OpenWebNetLightingHandler.handleMessage(OpenWebNetLightingHandler.java:275)
dic 15 21:06:33 OpenHAB karaf[891]: at org.openhab.binding.openwebnet.internal.handler.OpenWebNetBridgeHandler.onEventMessage(OpenWebNetBridgeHandler.java:606)
dic 15 21:06:33 OpenHAB karaf[891]: at org.openwebnet4j.OpenGateway.lambda$onMessage$4(OpenGateway.java:189)
dic 15 21:06:33 OpenHAB karaf[891]: at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
dic 15 21:06:33 OpenHAB karaf[891]: at org.openwebnet4j.OpenGateway$1.run(OpenGateway.java:271)
...
I attach the OpenHAB log file, the journalctl output and the service status output, run after a clean reboot.
I noticed that when the system becomes unstable the number of tasks has reached the limit (9566 in my case) and in the journalctl output I have a lot of error like this:
dic 12 06:09:00 OpenHAB karaf[894]: [46351,181s][warning][os,thread] Failed to start the native thread for java.lang.Thread "OH-JsonStorage-20814"
dic 12 06:09:00 OpenHAB karaf[894]: [46351,253s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 2048k, guardsize: 0k, detached.
dic 12 06:09:00 OpenHAB karaf[894]: [46351,253s][warning][os,thread] Failed to start the native thread for java.lang.Thread "OH-JsonStorage-20815"
dic 12 06:09:00 OpenHAB karaf[894]: [46351,254s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 2048k, guardsize: 0k, detached.
dic 12 06:09:00 OpenHAB karaf[894]: [46351,254s][warning][os,thread] Failed to start the native thread for java.lang.Thread "OH-JsonStorage-20816"
The system version is 4.3.0.RC1 on RPI 5 with 8GB and boot from SSD.
Only the Openwebnet binding and the Astro binding.
Any suggestions? Do you need more information?
Thank you
Giovanni
Hello,
I tested OpenHab 4.3.0 (in the hopes that I had missed in the prior releases that there was something related to OpenWebNet).
For me, the behavior for me is the same as when I tested with 4.2.1.
All items with A=0 still do not communicate with MyHomeServer1.
How can I raise the concern/voice louder? I am losing access/control to 10 items post OH 4.1.1
Thank you
1 Like
I think the issue everything with A=0 is now considered like an area or a group of lights, not that it does not read or accept anything with A=0
Same thing if I delete the items with A=0 and run discovery, they are discovered again (i.e being read) and the get added, but they come as area lights but no control.
Blockquote
|16:38:27.877|DEBUG|org.openhab.binding.openwebnet.internal.handler.LightAutomHandlersMap|MAP - Removed handler 1.h02 from Area -1|
|—|—|—|—|
|16:38:27.878|DEBUG|org.openhab.binding.openwebnet.internal.handler.LightAutomHandlersMap|Map: ---- LightAutomHandlersMap ---- - Area: -1 - 1.h0h3 1.h04 1.h05 1.h06 1.h09 1.h3 - Area: 0 - 1.0010 1.0011 1.0012 1.0013 1.0014 1.0015 - Area: 1 - 1.18 1.0111 1.14 1.15 1.12 1.13 1.11 1.0113 1.0114 1.0115 - Area: 2 - 1.0210 1.29 1.27 1.28 1.26 - Area: 3 - 1.0310 1.34 1.35 1.38 1.39 1.36 1.37 1.0315 1.0311 1.0312 1.0313 1.0314 - Area: 4 - 1.42 1.0411 1.0412 - Area: 5 - 1.56 1.57 1.55 - Area: 7 - 1.7 - Area: 8 - 1.08 - Area: 9 - # getAllHandlers: 1.h0h3 1.h04 1.h05 1.h06 1.h09 1.h3 1.0010 1.0011 1.0012 1.0013 1.0014 1.0015 1.18 1.0111 1.14 1.15 1.12 1.13 1.11 1.0113 1.0114 1.0115 1.0210 1.29 1.27 1.28 1.26 1.0310 1.34 1.35 1.38 1.39 1.36 1.37 1.0315 1.0311 1.0312 1.0313 1.0314 1.42 1.0411 1.0412 1.56 1.57 1.55 1.7 1.08 # getOneHandler() = 1.42 -------------------------------|
|16:38:27.878|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetBridgeHandler|Removed APL 1.h02 from lightsMap|
|16:38:27.878|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetBridgeHandler|un-registered device ownId=1.h02|
|16:38:27.878|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetBridgeHandler|registered device ownId=1.h02, thing=openwebnet:bus_on_off_switch:MYHOMESERVER1_000350a4baef:02|
|16:38:27.879|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler|associated thing to bridge with ownId=1.h02|
|16:38:27.879|DEBUG|org.openhab.binding.openwebnet.internal.handler.LightAutomHandlersMap|MAP - Added handler 1.h02 to Area -1|
|16:38:27.879|DEBUG|org.openhab.binding.openwebnet.internal.handler.LightAutomHandlersMap|Map: ---- LightAutomHandlersMap ---- - Area: -1 - 1.h0h3 1.h02 1.h04 1.h05 1.h06 1.h09 1.h3 - Area: 0 - 1.0010 1.0011 1.0012 1.0013 1.0014 1.0015 - Area: 1 - 1.18 1.0111 1.14 1.15 1.12 1.13 1.11 1.0113 1.0114 1.0115 - Area: 2 - 1.0210 1.29 1.27 1.28 1.26 - Area: 3 - 1.0310 1.34 1.35 1.38 1.39 1.36 1.37 1.0315 1.0311 1.0312 1.0313 1.0314 - Area: 4 - 1.42 1.0411 1.0412 - Area: 5 - 1.56 1.57 1.55 - Area: 7 - 1.7 - Area: 8 - 1.08 - Area: 9 - # getAllHandlers: 1.h0h3 1.h02 1.h04 1.h05 1.h06 1.h09 1.h3 1.0010 1.0011 1.0012 1.0013 1.0014 1.0015 1.18 1.0111 1.14 1.15 1.12 1.13 1.11 1.0113 1.0114 1.0115 1.0210 1.29 1.27 1.28 1.26 1.0310 1.34 1.35 1.38 1.39 1.36 1.37 1.0315 1.0311 1.0312 1.0313 1.0314 1.42 1.0411 1.0412 1.56 1.57 1.55 1.7 1.08 # getOneHandler() = 1.42 -------------------------------|
|16:38:27.880|DEBUG|org.openhab.binding.openwebnet.internal.handler.OpenWebNetBridgeHandler|Added APL 1.h02 to lightsMap|
Blockquote
Hi,
I suspect that the developer is not active any more as there haven’t been answers from him for a long time.
The non communication is not caused by the group of lights but because of a software block in the code.
If only I could modify the code to remove this block… nevertheless I will try to look into it.
Thanks Oppo,
I do hope @massi comes back.
Doing more debugging after adding the discovered group of lights and trying to turn / on and off i get the following
Blockquote
16:54:33.607 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler handleCommand() (command=REFRESH - channel=openwebnet:bus_light_group:MYHOMESERVER1_000350a4baef:7:switch)
16:54:33.607 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler requestChannelState() openwebnet:bus_light_group:MYHOMESERVER1_000350a4baef:7:switch
16:54:38.608 DEBUG org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler requestChannelState() TIMEOUT for thing openwebnet:bus_light_group:MYHOMESERVER1_000350a4baef:7
16:54:38.608 INFO openhab.event.ThingStatusInfoChangedEvent Thing ‘openwebnet:bus_light_group:MYHOMESERVER1_000350a4baef:7’ changed from UNKNOWN: Waiting state update… to OFFLINE (COMMUNICATION_ERROR): Could not get channel state
Blockquote
I just hope we can resolve it, as I would need to continue upgrading Openhab as I have other bindings and it’s a nightmare scenario to start moving away completely.
Maybe a Christmas Miracle
How hard is it to roll back and re-apply what was there in 4.1.1 and apply it post-4.3?
Hello again and a happy 2025.
Does someone has to knowledge to take the jars of the prior version (working on 4.1.1) and compile it in a way to use the jar externally with Openhab?