Since the upgrade or are you sure they did not show up before?
After the update, no channels show up in deconz things (switches, dimmers). I have also already cleared the cache. Unfortunately without success. It only helps if you delete the thing and create it again.
After the update. I’m 100 percent sure I haven’t seen them before.
You should be more specific. What exactly is not working with the http binding? Logs?
I’m having problems with the Verisure binding in 3.1.0. Not 100% sure if it’s due to 3.1.0 or something else, because I broke my SD card and started from scratch again. But for sure it’s not working. See my post below. Verisure binding stopped working
I’ve upgraded my docker container from 3.1.0.M5 to 3.1.0 went smoothly except for the Homematic Binding. Some of my Homematic things are shown as Config:Error, mostly Homematic IP devices. The error says that device-id “xyz” is not found on gateway-id “abc”. Reverting back to 3.1.0.M5 solves the issue and everything works as expected. (Also the 3.1.0.RC1 had the same issue)
I’m using Raspberrymatic for the Homematic CCU in Version 18.104.22.16810525. Docker is running on Ubuntu 20.04 with the latest updates.
I’ve no idea what went wrong or where I can look for a more detailed error log.
Also trying the 3.2.0-snapshot version didn’t helped.
Can someone lead my into the right direction or give me some tipps on what I can do?
I created an own topic for this specific issue: Update to Openhab 3.1.0 breaks Homematic Binding
…and I have a problem with some “NON”-IP-Sensors, they appear as online, but do not send any data.
3.1.0.M5 is working fine.
Err, well. There have been threads on each and every milestone, including code freeze announcement IIRC, plus as a long term user you should be aware of the release cycle and that it’s missing the projected date by a day or two at most - shouldn’t you ?
Sorry but to upgrade right around this date is just very bad timing of yours and that’s even more true for ad hoc action.
Sure it’s always nicer to get yet another announcement beforehand, on the other hand side how long do you expect devs to wait so everyone has “enough” time to prepare ? Not everybody is a daily forum user. No that wouldn’t work.
Plus you must not disappoint those eager to get hold of the final code asap.
Dear community members,
please only post to this thread if you believe your post is specific to the 3.1 release and of general interest to 3.1 users (or wannabes).
Any specific sort of problem of yours or issues that have been there in recent milestones already, please open your own thread. Remember just because an issue is new to you it’s not necessarily new to others.
If you don’t, this thread will quickly become overloaded and useless to all of us. Thank you.
PS: and mind the general posting guideline. Remember to provide at least a comprehensive description and code or logs that show the problem.
How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community
First: I know it’s mostly a spare time thing here and I’m grateful for each and everyone contributing their time and effort here.
With that out of the way: I beg to differ here! I did my openHABian “upgrade system” exactly 23minutes after Kai updated the sources. As you pointed out, users of openHABian should use the built in upgrade and not only “apt-get update && apt-get upgrade” - and I wanted to update the pi firmware, which fixed some security issues. If I did it in the shell, I certainly would have noticed that openHAB is about to upgrade also…
So, a short: “hello everyone, I’m about to update tonight!” in the usual announcement post is sufficient in my eyes. Kai posted the announcement after updating the sources, what’s different, if he could just posted the announcement a few hours beforehand to just achieve awareness, that something is about to happen. As with every announcement, all users should get an email from the board, so they’re informed.
but perhaps it could also be turned around to a feature in openHABian: as Rich pointed out openHABian could “lock” to a specific version or could inform the user beforehand, that not only the “normal” apt-get upgrade is going on, but a major/minor release is about to happen?
No, pinning definitely is something you can do manually in specific situations if you know what you’re doing, but we cannot generalize and automate that. That would lead to a huge bunch of new problems, definitely way worse than having a user or two stumble over their own unfortunate timing.
If it is exactly the same problem as described here Update to Openhab 3.1.0 breaks Homematic Binding post the exact messages from openhab.log.
If it is different please open a new topic or issue. If you don’t receive data from sensors please check the callback address in the bridge configuration,
MySQL JDBC Persistence no longer writting to the database after upgrade from 3.02 to 3.1. I made a separate post on that, which includes also the error details → Community Post with full Error Logs
→ Problem fixed - Reason was that OH3.1 persistence service doesn’t tolerate errors in item types (ON/OFF item was changed to String). This was tolerated/ignored by the OH3.02 persistence service.
Upgrade was successful without issues.
Actually I was able to remove the manually added bindings
http (pre-emptive basic authentication)
icloud (FIX: response invalid: null)
Thanks to all of you for your great work!
I also got this same issue when I upgraded today. Everything else went smoothly and it even gave me an excuse to cleanup the jsondb files
My work around on the UniFi binding was to enable the UnifiOS setting - save - wait for it to fail (I’m not running that OS) - then disable the OS switch again and resave = ONLINE =
Thanks for the hint @DOliana
Did the 3.1 upgrade through openhabian, reboot but facing problem that openhab is no longer working. no log generated (also empty IP:9001), no access to IP:8080. Grafana (IP:3000) can be opened (framework is loading) but no data from influxDB. Via console openhabian can be opened. …not sure where it got stopped during boot sequence…
Any idea how to recover?
I have started a post with this issue, I don’t find any information about it, and I don’t know if someone has this problem.
Updgrading from OH 3.0.2 to OH 3.1.0 break Xiaomi Mi Smart Home Binding, and reports a error in Kraft Console (this is under Windows 10).
Any information would be apreciated, as all Xiaomi devices are currently not accesible.
Has anyone had any issues with ZigBee binding after the update? I’m on x86 openHABian upgraded from 3.0.1. The ‘Upgrade System’ option didn’t update so needed to do a apt-get update && apt-get upgrade.
Once update was complete my Zigbee items show as online but don’t respond. I then removed one device and re-paired and shows as an Unrecognised device with no channels and offline. Zigbee has always been really flakey for me with devices going offline, maybe it’s time to give mqtt2zigbee a go
Not really openhab, but my default html nginx page was reset to the default one so had to recreate it.
Other than that my 20+ things/bindings all online and working great. Thank you for all your good work!!! Love openHab, just wish I could crack reliable Zigbee devices!
It seems that the DenonMarantz binding changed.
Sending commands seem to work:
general#power --> OFF
The other way around (update from Denon) does not update the channel.
I need to investigate this further, but the same applies to
3.0.2 did not have these issues.
Anyone else with this issue?
I just upgraded from 3.0.2 using the AUR package on Arch Linux ARM (Raspberry Pi 4B), and OH doesn’t start since. Running
/usr/share/openhab3/karaf_wrapper.sh server manually only produces one probably unrelated line:
org.ops4j.pax.url.wrap [org.ops4j.pax.url.commons.handler.HandlerActivator] DEBUG : Handler for protocols [wrap] started
and the log files in
/var/log/openhab3/ stay completely empty. The Karaf console starts fine and is accessible over SSH, but there’s no trace of OpenHAB itself.
I downgraded back to 3.0.2 for the time being and everything’s working fine again. Does anyone have any ideas?
EDIT: Alright, after deleting
/var/lib/openhab3/cache/ everything works fine.