My MQTT also stopped working.
Upgraded from M6 to RC1
csowada/ebus
This library handles the communication with heating engineering via the eBUS specification. This protocol is used by many heating manufacturers in Europe. - csowada/ebus
My MQTT also stopped working.
Upgraded from M6 to RC1
MQTT issues as described above - same here.
Commands sent
State Updates fail
MQTT or MQTT1 binding?
The MQTT 2.X binding
Please open an issue on GitHub if there is not already one.
I will but now I’m trying to reproduce the problem on my test system with some meaningful log.
Bruce…
I didn’t created a new issue because someone already created one.
Added my own logs there:
I would have expected the issue to be filed here.
This library handles the communication with heating engineering via the eBUS specification. This protocol is used by many heating manufacturers in Europe. - csowada/ebus
Not sure if this is new “feature” or an unintended consequence of recent changes, but it seems that every time I use PaperUI to add or delete a Thing or Item, an OpenHAB System restart is initiated. This did not seem happen prior to 2.5.0M6. I am running OpenHAB in Docker. Did I miss something along the way?
UPDATE: This issues seems to have resolved. I rolled back to 2.5.0M5, deleted the cache and tmp directories, updated to 2.5.0RC1 and restarted the docker 2 twice. Since doing this I have not noticed any restarts when I add Things or Items using PaperUI. I believe this glitch is real, but was easily resolved at least for now.
I love music and nice sounds, but headteacher’s tone is not for a community of volunteers.
I see the same behaviour. I have a TRACE log, but doesn’t see anything suspicious.
It is only subscriptions, publish works fine as somebody alread has written.
If needed I would be happy to test any changes, just give me the jar file
See the GitHub issue
Who actually decides what is a critical issue?
For me, for example, it is critical if the “nightly zwave heal” does not work. Or if my Philips Hue dimmer and Tap switches events will not work.
They are still NOT SOLVED since 2.5.0.M1 or 2.5.0.M2.
See here:
Z-Wave heal:
S1602 Zwave 2.5.0.201905280446 (not a manual install) HUSBZB-1 @cdjackson, …
Logging this as an issue so we can keep track of it. For some battery devices…
Philips Hue (Dimmer and Tap Switches):
Parallel to my “production” setup i got a docker container with the current 2.5 Milestone Build M4. I found out that lights that i control with the Philips Hue Dimmer Switch via the Milestone Build i got unreliable events from the button. Here is the events.log port of the M4 Build: 2019-11-01 13:47:00.658 [vent.ChannelTriggeredEvent] - hue:0820:00178827902c:Zigbee_Kueche_Fernbedienung:dimmer_switch_event triggered 1002.0 2019-11-01 13:47:04.833 [vent.ChannelTriggeredEvent] - hue:0820:0017882…
I have a rules file that monitors multiple Hue dimmer switches. It was working fine under 2.4.0. Updating OpenHAB2 to version 2.5.0-M1 seems to break the Hue dimmer_switch_event channel as I can’t see any activity on it. I also didn’t notice anything in the changelog that would suggest any syntax has changed for rules files. Downgrading back to 2.4.0 made the problem go away immediately… This might not be specific to the Hue. Anyone else seeing something similar?
After upgrading openhab to 2.5.0.M1 this does not always work
While migrating Hue Dimmer Switch and Hue Tap rules from the Hue bridge to OH 2.5.0.M1, I noticed that the binding seems to be missing button events. For instance, many times when short pressing and releasing button 1 of the Dimmer Switch, only the initial pressed (sometimes) or short released (mostly) is triggered, and sometimes neither. To rule out the bridge itself or interference on the ZigBee mesh network that is causing this, I added a Dimmer Switch Rule (see below) to the bridge that tri…
Do you seriously want to tell people that a stable release somehow works, but you better should disable the nightly zwave heal. And all your Hue Dimmer Switches and expensive Tap Switches will not work? Well then…
In the documentation, it is promoted or proclaimed that this works, actually since 18th January 2019 (Hue) and since mid-May 2019 (Zwave heal) they do no longer work. Then please change the documentation. Thank you very much.
I am absolutely on Celaeno1 side.
My primary device to control everything in the house are the cheap philips hue dimmer switches. If they are not going to work i won’t be able to migrate to 2.5. However as i am not capable of contributing code to the project. I tried to make clear that i got the same issue on this forum as well as on github.
I can understand the decision of cweitkamp who did the last change in the hue binding and doesn’t use the dimmer switches anymore, as it is his free time that he is contributing to this project.
However my conclusion for this is to move to another meta smart home controller like hass.io or nodered which still supports my hardware as i won’t have any other choice than that.
If there is anything else except for contributing code what i can do i am absolutely willing to pay 50€ to get the support of the dimmer switches back, however i don’t think that this won’t be a acceptable price as the development will take more than half an hour for the contributor.
Cheers
Andreas
my Philips Hue dimmer and Tap switches events will not work.
Sorry if this is maybe a stupid question, but did anybody ever file a bug report about this?
Looking at Pull requests · openhab/openhab2-addons · GitHub, I cannot see anything related…
I can understand the decision of cweitkamp who did the last change in the hue binding and doesn’t use the dimmer switches anymore
You mean @cweitkamp broke the code and decided to not fix it, because the feature isn’t relevant for him? From all I know about his work over the past years, I cannot believe this…
Please read this:
@Celaeno1 I appreciate your eagerness to find a solution for this problem. But I am afraid I do not have the time to investigate much on it at the moment. In general I guess that we are facing two different problems here. First one is the Philips Hue Event issue. This is probably cause by the polling strategy implemented in the binding - it polls the Hue Bridge in a fixed time interval. For this issue I have to admit that I am not very motivated to do research as I get rid of sensor / remote con…
I very well appreciate all the work of Christoph. Thanks a lot. But unfortunately above is true.
One issue is filed here:
Hej there, I (and others) run into the following error when trying to fetch t…
One issue is filed here: [ERROR] using receivedEvent.getEvent() in a rule · Issue #706 · openhab/openhab-core · GitHub
Which is unrelated to the hue binding itself and which does not seem to be reproducible…
But there’s no issue entered over all these months about the hue binding?