Time to say Goodbye

[David_Graeff]

@erichabg

For clarification: The original and fundamental mistake is not that any binding no longer runs, but the entire openhab runtime system was destroyed after a simple apt update (“Unresolved requirements”).

openHAB != the apt package. It is very human if one of the apt package guys (volunteers) made a mistake in the process. Next time (maybe with another software solution), wait a bit before doing the upgrade after a release. Take MS Windows for example. There were 3 updates this year, that under certain conditions could totally corrupt your operating system installation.

My production system is still on an older release, because I know that it might take a day to first get the basics running and then adapt binding configurations.

But: The migration from OH1 to OH2 is almost complete. All heavy impact bindings are rewritten (OneWire, KNX, MQTT, … HTTP is also coming soon) and for all other existing bindings thanks to static code analysis almost all configuration errors have been caught. I do not expect many breaking changes anymore (as long as you use OH2-only concepts at least).

Cheers, David

[erichabg (Erich Freibert)]

@J-N-K

I‘m still willing to help with the OneWire binding. But since discovery works for a lot of people, something must be different in your setup. Either you have a lot of sensors that are not supported (if so, just let me know and we‘ll find out how we can add them, some are easy, others need more work and take some time) or for some reason they are lot listed in the owfs (that could be due to DS2409 hubs or similar, this is on the list but will take some time.

Thanks for the offer, I’ll get back to it as soon as I have more time.
And yes, there are some onewire hubs in my network (but more than 2 devices are connected directly without hub). Some years ago even Paul (Alfile if I remember correctly) was debbuging his owfs implementation in my network. Afterwards all subsequent versions of owfs were running like a charm .
What I don’t quite understand, however, is why the connection via the hubs plays a role. Isn’t this handled independently by the owserver and you just have to ask the server? At least I do that with my PHP and python scripts accordingly.

But please give me time until my frustration has subsided and I find peace again to tackle the problem. Currently I have switched back to V1 binding and it works.

[fuslwusl]

I updated to onwire2 Binding using a things file. Textual config worked like a charm. Updating was just a bit copy and paste using multicursor feature of visualstudiocode. Openhab and all bindings work rock solid with hundreds of items. Thanx for the great work to all developers!

[Lionello_Marrelli]

Let me add my little bit. I’ m not a programmer at all, even though I use some scientific programming language at work. I have a working Openhab 1.8.3, since a couple of years, on a raspberry pi v3. It took me a considerable time to develop it with my limited knowledge but now it works satisfactorily and reliably. Automated daily backup with raspiBackup on a synology NAS allowed me to recover from an sd crash in a relatively short time. I used python scripts to obtain features unavailable in openhab at that time and I slowly improved the site maps over time, still by trial and error or asking for help on the forum.

Now OpenHAB2 is out and it delivers improved features: unfortunately, even though someone spent considerable time in documenting a migration tutorial, I’ve not been able to perform the upgrade. This is due to the fact that I use a binding that have been rewritten for OpenHAB2 and possibly to the fact that I implemented rules with poor programming standards.

I’ve not given up though. I’m using a second Raspberry for development, running simultaneously with my old production one and I slowly add functionality using OpenHAB2. Lots of pitfalls, due to my limited knowledge, slow down this process: i.e. Version 2 of the exec binding only return strings (while v1 returned numbers), or summing numbers in rules is not possible if one comes from an item with a dimension (I. E temperature) and the other doesn’t. …
So far the UI looks much better, but I still have to decide which way to go for some components: continue using external python scripts with old but functioning libraries or use bindings (which are not officially supported, such as the broadlink or the old fritzaha).

In summary: I won’t upgrade my system unless necessary or desirable for new features, but i will start with my development one.

Let me conclude by thanking all developers and experienced users that help he community for free,
Lionello Marrelli

[vzorglub (Vincent Regaud)]

@Lionello_Marrelli

or summing numbers in rules is not possible if one comes from an item with a dimension (I. E temperature) and the other doesn’t. …

Yes, you can, just convert your unit item to plain numbers and then do your math:
For example:

            val offset = House_HeatingOffset.getStateAs(QuantityType).doubleValue
            val target = (Targets.members.filter[ i | i.name.contains(room) ].head.state as QuantityType<Number>).doubleValue
            val ambient = (AmbientTemps.members.filter[ i | i.name.contains(room) ].head.state as QuantityType<Number>).doubleValue
            if (ambient <= (target - (offset / 2))) {

Here I use the 2 options to convert a QuantityType to a plain vanilla Number:

var Number myNumber = myItem.getStateAs(QuantityType).doubleValue
var Number myNumber = (myItem.state as QuantityType<Number>).doubleValue

Both return the same

[Lionello_Marrelli]

@vzorglub

Yes, you can, just convert your unit item to plain numbers and then do your math:

You are right, I was imprecise. But let me express my frustration (which may be similar to the one felt by the OP author) by detailing how I figured out a solution. If this is not the right thread you can delete it or move it elsewhere.

I knew from OpenHAB1 times that the item state has to be converted to DecimalType or Number: but why should I convert it twice? and why doesn’t the interpreter complains with a type mismatch error or something similar?

Let me detail my situation: in this way maybe I (an possibly others) will learn something more about Java object oriented programming.

Items definitions

Number Te_Br_CameraAnna	    "Temp Anna  [%.1f %unit%] " <temperature>   {channel="broadlink:a1:3a0e28c9:temperature"} // actual temperature
Number:Temperature TempAnnaLow  "Stanza Anna Temp Bassa [%.1f]" //set point

sitemap definition of the set point

Setpoint item=TempAnnaLow  label="Temp Bassa [%.1f %unit%]" minValue=15 maxValue=25 step=0.5

NON WORKING thermostat rule (excerpt)

    var Number ActualTemp
    var Number Delta=0.2
    var Number setPoint
    var String tmp
    var Number Temp

    setPoint = (TempAnnaLow.state  as Number)
    ActualTemp = (Te_Br_CameraAnna.state as Number)

    Temp=ActualTemp - (setPoint - Delta)
    tmp="This condition gives a wrong result " + Temp
    logInfo("ThermostatRule",tmp)
 
    if((ActualTemp - (setPoint - Delta)) <= 0 {  
// switch on thermostat etc...
       }

WORKING thermostat rule (excerpt)

    var Number ActualTemp
    var Number Delta=0.2
    var Number setPoint
    var String tmp
    var Number Temp

    setPoint = (TempAnnaLow.state  as Number).floatValue       // added further conversion
    ActualTemp = (Te_Br_CameraAnna.state as Number).floatValue  // added further conversion

    Temp=ActualTemp - (setPoint - Delta)
    tmp="This condition gives the right result " + Temp
    logInfo("ThermostatRule",tmp)
 
    if((ActualTemp - (setPoint - Delta)) <= 0 {  
// switch on thermostat etc...
       }

I figured out the solution of adding “.floatValue” by debugging line by line and thanks to the the fact that the conversion to string works for almost everything and let you print out the content of the variables no matter what they are. But I am confused and let me explain why.
setPoint, ActualTemp and Delta are declared as “Number” variables
When I assign a value to setPoint and ActualTemp I convert to “Number” with the “as Number” syntax.
Delta is a “Number” that I directly defined in the rule (though without units).

I was very surprised to see that SetPoint-Delta was giving a wrong result: after all, they were two “Number” variables!
I found somewhere in the forum (I was unable to find it in the docs, probably because this is obvious to Java programmers) about the required further conversion to float by adding “.floatValue”.

To me this behavior appears more like a bug than a feature, but I’m not a Java programmer therefore I ignore a lot of subtleties.

In any case, let me conclude as in my previous post: OpenHAB2 is an open source project developed for free by a lot of skilled developers willing to share their knowledge and used by experienced users willing to help less experienced ones: the drawback is that documentation is not complete or fully up-to-date, and an help-desk is not available. This is ok for me, but I understand that someone else may not be happy with that.
Lionello Marrelli