Preparation for 2.5M2

Setup, Configuration and Use Runtime
61

If I’m not mistaken, there are still problems building the zigbee binding? There’s an open PR to update the ZSS library to v1.2.1.

I don’t know if this should make it into M2, maybe @chris can elaborate.

62

I have not checked in about a week but I think the api docs broke again. It could not load the JSON file.
Since I am experimenting with the API I moved back to the M1 build.

63

Yes, there are still problems. Maybe they are resolved this morning as I’ve seen some mails, but I’ve not tried myself.

1 Like
64

I don’t think so. One could make a note in the docs for the binding perhaps.

It’s mainly the Homie stuff that is experiencing problems if I understand correctly. I imagine the HA stuff might have some similar problems as well, though I’ve not seen any reported yet though I don’t follow the Issues as closely as some.

In my experience so far, the Generic Thing stuff works pretty well, well enough that I wouldn’t call it experimental.

I can confirm. I updated to the latest snapshot yesterday and I’m getting

Can't read swagger JSON from https://openhab.koshak.us/rest/swagger.json

I don’t see that in the list in the OP. I couldn’t find an open issue so I created one.

@5iver, should this be added to the list? The REST API Docs are pretty important for some use cases.

1 Like
65

That’s why I reinstalled to 2.5M1.

66

I expected this one was going to be fixed pretty quickly, but go for it. Your issue should be in OHC though and likely related to openHAB JAX-RS publisher by maggu2810 · Pull Request #905 · openhab/openhab-core · GitHub.

1 Like
67

Just as a reminder: We have https://github.com/openhab/openhab-distro/projects/2 for tracking the really critical issues, so if you have open issues that MUST be fixed for M2, please ask here to have them added (all openHAB-Distro maintainers should have the rights to do so).

Some bad news: Meanwhile, we again have issues with the build pipeline, see https://ci.openhab.org/view/Sandbox/job/sandbox-openhab2-release/ - we didn’t have a successful build for more than 2 weeks again, so this is something critical that needs to be addressed as well, before we can do a milestone build :cry:.

2 Likes
68

It appears that the failing build is only due to one missing POM file:

[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/openhab/util/pax-web-patch/1.0.0/pax-web-patch-1.0.0.pom
[WARNING] The POM for org.openhab.util:pax-web-patch:jar:1.0.0 is missing, no dependency information available

2 Likes
69

(Small Remark: The problem of the last day has meanwhile been solved)

2 Likes
70

There we go. The build is up and running again. Thanks @kai for the quick fix after @shutterfreak analysis.
Now it’s “only” about solving the bugs seen as critical.

6 Likes
71

I’ve been trying to track an issue down for a few days and I’m at a loss at this point. Since moving from M1 to the M2 nighties I’ve noticed that some of my rules are, what I can only say from “gut feel”, not multi-threading properly. Where things would run in parallel before they now run serially.

I’ll give an example that may help. I use Sonos speakers across the house with PollyTTS to send auditory alerts for different things. Each Sonos has a separate (but identical and generated by script from a template) set of rules to make this work properly. On M1, all 4 speakers would fire almost at the same moment (assume a few milliseconds of lag at most for >95% of the time). Now, for no reason that I can find, they fire serially. Duration of what is said is irrelevant. One second or thirty seconds, they fire one at a time. One will speak, then the next, and so on until they all speak. I’ve gone through and increased all of the relevant org.eclipse.smarthome.threadpool items in services/runtime.cfg to make sure there are enough threads available.

I’ve also noticed that the updates to the bus by the rules can be severely delayed (order of seconds). Again, not sure why this is happening but when comparing the log files I can see the logInfo pop out of my rule and then the events.log shows the item update much later. It’s almost like some thread is getting hung up and holding up the updates. Historically I would see no more than a 250ms lag.

From a hardware perspective, my OH2 instance runs on an Ubuntu VM in an ESXi cluster. The servers are xeons with lots of ram. The VM itself has been given a substantial amount of CPU and RAM to see if that helps. It seems to have almost no impact. I’m on nightly 1640 right now also for reference.

Again, this is just a gut feeling of where the problem may be based on observation.

1 Like
72

I remember a PR on core that spoke of this between @maggu2810 and @Kai

73

@morph166955 This sounds a bit like the effects I was afraid to see in this comment. We weren’t able to find any reproducible proof for such concerns. If you can come up with a simple setup that shows the difference, it would be perfect. I am aware that this might be very tricky as it requires certain hardware like Sonos speakers, but that would be ok. If you could describe this in a new issue at https://github.com/openhab/openhab-core/issues, it would be much appreciated!

2 Likes
74

Besides the last regression mentioned above, does anybody have further critical issues that need to be addressed and that might render a complete binding unusable at the moment? @J-N-K, are the 3rd-party lib issues with AllPlay, Bluetooth, etc. fully solved?

1 Like
75

The best way to reproduce that I can give you is my own system design. Effectively this is how my rules work:

  1. Something triggers a need for a voice output (door opening, whatever).

  2. Response is generated and sent to a string item that is not associated with any specific channel/thing/binding. Mine is called SPEAK_APB (as in all points bulletin).

  3. I then have this rule:

    rule “Speak APB”
    when
    Item SPEAK_APB received command
    then
    var String state = receivedCommand.toString()
    SonosOneRINCON_Speaker1_AddSpeakQueue.sendCommand(state)
    SonosOneRINCON_Speaker2_AddSpeakQueue.sendCommand(state)
    SonosOneRINCON_Speaker3_AddSpeakQueue.sendCommand(state)
    SonosOneRINCON_Speaker4_AddSpeakQueue.sendCommand(state)
    end

This in theory creates the separation simultaneous actions.

  1. Every second I then have a cron run for each speaker to check the AddSpeakQueue. I use the queue mechanism so I don’t lose outputs in the event that something is put into the queue while the speaker is already speaking. Effectively each speaker rule is below. I’ve trimmed it down substantially just to provide the concept. Also to note, each rule is in a different file.

    rule “Speak Queue Speaker 1”
    when
    Time cron “* * * * * ?”
    then
    var String speakstate = SonosOneRINCON_Speaker1_AddSpeakQueue.state.toString
    SonosOneRINCON_Speaker1_AddSpeakQueue.postUpdate("")
    var String sonossink = “sonos:One:RINCON_Speaker1”
    var Number sonosnotvolume = Integer::parseInt(SonosOneRINCON_Speaker1_NotificationSoundVolume.state.toString())
    var Number speakvol = new PercentType(sonosnotvolume.toString)
    say(speakstate, “pollytts:Brian”, sonossink, speakvol)
    end

There are a few other safeties I have in my code which aren’t relevant here. Mostly to fix issues that cause the speakers to act funny. This code, while probably more complicated than it should ever have had to be, worked flawlessly on M1 for months.

76

As far as I know

  • Allplay works

  • Bluetooth works on arm but not x86-64, not sure about x86. I prepared a test-bundle that may solve the problem but did not receive feedback from the reporter. From my understanding we are at the same point where we have been in 2.5M1

  • amazondashbutton fails under some circumstances (depending on the pcap used). This may or may not have been present in 2.5M1.

77

I still hold to everything in the OP…

  • Hueemulation is completely unusable
  • Zwave is also severely crippled since the network heal needs to be disabled and I have suspicions about the issue mentioned above effecting this binding too, but I tried reverting the removal of safecaller and it did not resolve my issues.
  • Caldav is completely broken
  • TMK, the ephemeris configuration is also still broken
  • MQTT2 is working for my purposes, but I’ve seen a lot of issues reported and hopefully Jan’s work to swap out paho would solve most of them.

It would be nice to see these in your official list :slight_smile:!

1 Like
78

We can fix some MQTT issues independently from the Paho-issue. I can‘t promise anything, maybe next week when it‘s too hot to do gardenwork. The Paho thing needs some testing and should be done after M2.

2 Likes
79

@Kai There seems to be an issue with JuPnP on the nightly builds as well. I see this also with the Sonos speakers. For some reason, the JuPnP bundle just stops working from time to time. I’ve had to create a rule that monitors the state of each thing using getThingStatusInfo(mything).getStatus().toString(). The rule looks for when all of the Sonos speakers to go offline. At that point it runs “executeCommandLine(”/usr/bin/ssh -p 8101 -i /home/openhab/karaf_keys/openhab.id_rsa openhab@localhost bundle:restart org.jupnp", 120000)". That seems to fix it for between a day and a few weeks. The last time I saw it blink out was on 1633. It has not happened since, but I just updated to 1640 from 1633 so it may not have had enough time to fail.

80

This one looks relatively severe: