great work. im guessing this is pre the version which drops support for the old firmware which was committed a day or so ago.
Itâs based on todayâs master branch, so, yes, indeed, the support for the old firmware was already dropped.
sweet I will give this a go. I updated yesterday to get those changes but still found that the gateway didnât always come online and I certainly still get those piggy backed responses.
I will give this a try, thank you.
So far so good. gateway came straight online. lights seem responsive (no delays). so far no piggy back messages which use to come in fairly quick.
I dont want to speak too soon, but you might have just fixed this.
Are you going to monitor when the new version is released and log an issue to get it updated in openhab?
Cool, lets see if it remains stable for you as well. Waiting for 2.0.0 and creating an issue sounds like a plan. Unfortunately this involves a change in openhab-core, but that should be managable. 
Do not worry about that. We are happy about anyone helping with such nasty issues. If you need a hand feel free to ask me for help. 
Please loop me in while integrating Californium 2.0 into the core. Iâm working on the Shelly binding, which also supports Coop. However this requires a PR to Californium 2.0 itself, because Shelly uses non-standard extensions. I already have contact to a developer, which wants to see an integration to the official distribution as a pre-requisite to accept the PR. @cweitkamp How could we manage communication with the Californium team? AFAIK they will officially release 2.0 in October so timing could be perfect.
Gateway just went offline. Up until then it was perfect and very responsive. I had to reboot the gateway, but also change the ip to something else and back to the actual ip, before it would come online again.
So yes the gateway seems to be unstable but also seems like there is an issue in the binding as i shouldnât have to toggle the ip. Seems like when it goes offline, something doesnât get completely destroyed, which changing the ip causes it to do.
Piggy backed stuff has cleared up though. So the purpose of the build you provided has indeed fixed that.
Edit: It could be this as I had two updates on remotes which were still pending which have now gone through. https://www.reddit.com/r/tradfri/comments/d6qr4o/credit_where_credit_is_due/
Chris
@chriscolden Would be interessting to see if it really was the battery thing that crashed it. Mine is now running for the longest period ever (almost 1 week) and both, the ikea app and openhab are still working.
@flo-02-mu I will reset everything again and will keep an eye. I have no more pending updates so thatâs ruled out now. I do have quite a few devices, so it would be interesting to compare that if mine is still unstable.
@flo-02-mu Gateway has gone offline again, although seemed to last a bit longer this time. Itâs still working through the app and google home just not openhab.
Edit: Went offline after 1 day. Last reboot was yesterday. Iâve taken it off my poe injector and gone back to the standard power supply. I doubt this will make a difference, I had the issue before moving to the poe injector, but thought Id best rule it out.
Edit 2: Switching to official power supply has made no difference.
From my point of view a GitHub issue is the best place to discuss further steps. Everyone involved could participate if he likes it is needed.
1 Like
@markus7017, @cweitkamp I created Upgrade Californium to 2.0.0 · Issue #1096 · openhab/openhab-core · GitHub as a shell. Not sure how this will help the chicken-egg-situation around @markus7017âs PR, but sooner or later weâll need the update anyway.
Makes sense, Iâm working with Achim from the Californium team to make the PR as simple as possible. There is a good chance that this will go into 2.0-M18 and could be the basis for a new OH feature.
Achim also supposes that the bug you encountered was fixed in 1.0.7 whereas OH brings 1.0.6. So an update to 2.0 makes sense. Finale release is expected by end of the year.
Question: How do we deal with 2.4 installations?
AFAIK âopenhab.tp-coapâ feature uses version 1.0.7.
To be honest: I would not put much effort in support for OH2.4. We will have a major release for OH2.5 by the end of the year too. Hopefully after Californium.
an additional feature for 2.4? Is just packaging that together and providing that as part of the 2.4 repo (or an alternate download location). Would it be enough to copy those additional jars in the download folder? Then this would be easy to complete a 2.4 installation.
Yes, it is. Compile the binding and put the resulting *.jar file together with all depending *.jar files into the addons/ folder will be sufficient.
If you provide a *.jar file in your private repository you can also update the binding on the console - similar to these instructions - that will work with the Californium bundles too (you need to know the location of them):
openhab> bundle:list | grep Chromecast
213 â Active â 80 â 2.5.0.201910030417 â openHAB Add-ons :: Bundles :: Chromecast Binding
openhab> bundle:update 213 https://github.com/wborn/openhab2-addons/releases/download/chromecast-multizone-status-tag/org.openhab.binding.chromecast-2.5.0-SNAPSHOT.jar
openhab> bundle:list | grep Chromecast
213 â Active â 80 â 2.5.0.201910031158
ok, so we have already a solution for that
- I put the Californium jars in the bindingâs private repo and
- include the feature:install in the documentation
I found a solution, which requires a very simple PR. Achim expects that it will be part of M18.
I think you misunderstood my comment: You may provide a compiled binding jar in your private repository / fork of openHAB Add-ons repository for OH2.4. Do not add the Californium jars in the bindings private repo. It is possible to download them from public accessible services like Maven Central or their own GitHub repository.
Sounds good. It has already been merged, right?