Yes - openHAB 2.3.0-1 (Release Build) on a Raspberry Pi
How would I upgrade to Milestone 4 ?
If you are running openHABian, execute sudo openhabian-config and go to 40 openHAB related and select openHAB testing under 41.
Otherwise switch to the Testing release repo and run sudo apt-get update; sudo apt-get upgrade.
See https://www.openhab.org/docs/installation/linux.html#installation
Ok - will give it a try. Sorry for asking so many questions. I am learning.
I updated as you recommended without any issues. I then removed all my z-wave things and even the binding, did a reboot - added back the binding and it found the z-wave stick immediatly. It seemed easier than adding it previously as it also detected and added the serial thing.
It found the sensor but this time I let it have reasonable amount of time to analyse it. I triggered the sensor a few times.
It still does not recognise it but the page of information seems a little more complete. Do you think this is progress should I look for a different brand of sensor. I went with the same make as the z-wave controller as it seemed the easy way to avoid incompatibilities.
That’s a new feature.
If it bears the zwave logo then it should be fully compatible with all other zwave devices.
Do you still see the “could not resolve to a thing Type” message in the logs?
I did another reboot and watched the logs. Now it appears to be working. Phew.
I need to change its name but this is what I see in the logs.
2018-09-28 19:54:04.381 [vent.ItemStateChangedEvent] - ZWaveNode002_DoorSensor changed from CLOSED to OPEN
2018-09-28 19:54:06.299 [vent.ItemStateChangedEvent] - ZWaveNode002_DoorSensor changed from OPEN to CLOSED
2018-09-28 19:54:07.200 [vent.ItemStateChangedEvent] - ZWaveNode002_DoorSensor changed from CLOSED to OPEN
2018-09-28 19:54:08.025 [vent.ItemStateChangedEvent] - ZWaveNode002_DoorSensor changed from OPEN to CLOSED
2018-09-28 19:54:08.680 [vent.ItemStateChangedEvent] - ZWaveNode002_DoorSensor changed from CLOSED to OPEN
2018-09-28 19:54:09.260 [vent.ItemStateChangedEvent] - ZWaveNode002_DoorSensor changed from OPEN to CLOSED
2018-09-28 19:54:10.088 [vent.ItemStateChangedEvent] - ZWaveNode002_DoorSensor changed from CLOSED to OPEN
Thats probably all I can do today as it’s getting late. Tomorrow I will fix the sensor to the door and then I will need to look at rules and determine the best way to get alerted to the door being open, be that Google Home announcement (preferred) or iPhone app.
Look at Design Pattern: Motion Sensor Timer for how to deal with how to time the alert only when the door has been open for a certain amount of time. In this case the door sensor is the motion sensor.
I can’t help with the Google Home but suspect you will need to look at the Chromecast binding. I think a GH shows up as a Chromecast.
For the iPhone app, you will need to set up myopenhab.org and the openHAB cloud connector binding. As an added bonus, you will also be able to access your OH UIs remotely safely.
Progress update.
As I’m not sure how I use the code sample in the link (maybe i need visual studio or eclipse) I have created 2 simple rules using the web rules front end. One turns on the room lights when the sensor changes from closed to open, and the second turns the light off for the opposite condition. Happy with that.
With respect to some kind of audible alarm there seems to be 2 approaches. Either get a z-wave enabled siren or use a cheap buzzer which will come on whenever a socket/outlet is turned on/off by OH.
I think the deciding factor will be the support for a z-wave enabled siren. If nothing exists at the moment then it will be plan B.
I did notice that today when I looked at the switch from control panel it reported its battery life correctly so I’m guessing OH has been probing the device and learning about its capabilities,
I know they make zwave sirens. I’ve no experience with them though so you may need to do some searching to figure out what model fits best with what you want.
Note that the web rules is called “Experimental” for a reason. If it works for you great. But there is no documentation or users on the forum that will be able to help you much if/when you run into problems or can’t figure out how to make it do what you want.
The device reports once a day or so it’s current battery state.
I think i am the “Testing” build. Will I eventually be able to upgrade to a newer release from that ?
I have to admit that although OH is good I must have re-installed about 10 times for various reasons to do with SSD disks, releases, complete screw ups on my part. I guess this is where the robust nature of a less capable smartThings hub has an advantage.
Once it’s working and I have made multiple backup cards I won’t be so nervous. The good side of it is that I’m a past master at the setup that I’ve learned so far.
Can you explain the difference between the web gui rules and the "java script code"approach. Does the web gui create code that I can look at and learn from ?
Dave
Should I be feeding back any experiences regarding the testing build to someone ? for example immediately after installing the testing build and z-wave binding you get a message Error 500 - but it seems to go away after a while.
When the 2.4 gets released you will need to switch to the release repo to get the latest version. Or you can stay on the testing repo and wait for the first 2.5 milestone release.
Once you are up and running though, usually upgrades are really painless. However, sometimes there will be breaking changes in the new version that will require a bit more work on your part. This may be changes to the way Things for a given binding are defined needing you to recreate all your Things, a change in the Rules DSL requiring updates to your Rules, etc. These are usually rare but they do happen.
Just take backups using openhab-cli, or set up Amanda if you are on openHABian, or take card images (or a combination of all three) and you probably won’t suffer a catastrophic failure you can’t recover from.
Not javascript, Rules DSL. The two have nothing to do with each other.
Rules DSL is the legacy Rules engine. It is the most documented and most commonly used Rules Engine. The DSL part stands for Domain Specific Language. This means it is a custom language created specifically for openHAB. Pretty much all of the examples, postings, and documentation will be in Rules DSL.
Rules DSL is written in .rules files. You cannot create them from the UIs. See
The Experimental Rules Engine (ERE) is a new work in progress. It is completely separate from the Rules DSL. There is almost no documentation for it yet and it isn’t complete. Almost no one uses it yet so there will not be many here on the forum who can help yet.
Some simple Rules are already possible with ERE right now that do not even require code. However, how to write the code that will go in the JavaScript part is not well documented or defined and it isn’t clear how complete that is. So as soon as you need to do something that requires some code you will be on your own.
Yes and no. It creates code in JSON format stored in /var/lib/openhab2/jsondb but even though it is human readable it isn’t super human friendly. And looking there won’t really help figure out how to write the script part.
Your answers are always so comprehensive I feel guilty for asking stupid questions.
In this message thread you have mentioned that as I had to use a “testing” build to get OH to recognise the door sensor I would have problems getting support.
As you can see I will need support.
Would I be better off with a different type of door sensor, for example the smartthings sensors - I think the new version 3 hub has been released with new sensors which are better and cheaper than the previous ones.
Sorry for floundering around without making huge progress. I would like to stay with OH as (believe it or not) I’m a java programmer by profession - so I should be able to get familiar with it.
If I rebuild with a standard release version for the PI I know it will work with my w-wave stick - but the door sensor comes back as unknown. I also have in the back of my mind that you mentioned that the bindings were different in the latest version of the z-wave code - does this mean there is going to be a re-config exercise in the future if I use the current release with a compatible door sensor ?
Thanks in advance
Dave
The difference between the Release version and the Milestone versions are not all that great. Since you have the sensor you have recognized and working I would not change anything now. It is unlikely that there is anything that you will need help with that will be specific to the milestone release or that you will need more help for being on the milestone release. Even the snapshots are pretty safe in that regard.
Since you are a programmer, you might be interested in the JSR223 Rules. This will let you write Rules using a “real” language: jython, java script, or groovy. Many programmers become exceptionally frustrated with the limitations of the Rules DSL because it has very specific ways it wants you to do things and your typical idioms like functions and data structures are not available in the same way.
Yes, you will have to remove your Things and rediscover them.