Can you post a new set of logs and configs? It sounds like you’ve touched on some of the issues already, so it’ll filter out the chaff a little.
I’ve tweaked those instructions to include the corresponding apt-get that installs you the SVN client. The two commands, together, will do the right thing. The files will download to the current directory, so they just need to be moved to the configurations/transforms directory.
OH2 does this a little differently, including the OH1 “compatibility mode” that’s being developed. It’ll automatically download the relevant extras, so things like Images, Transforms, etc, will all be pulled down, so that part is a 1000% better.
[quote]And for the 3rd time, I’m asking HOW??? Just the logs, or is there something else I should be looking at?
[/quote]
It’s just the logs.
- Got
ERROR entries, get those identified and fixed before moving on to UI’s and such
You’ll see this as a common theme, starting simple, becoming familiar with how that part is working, and then making small changes to move to the next level.
- Got Stack traces, in either
openhab.log (default), or mios.log (custom), get those identified and fixed
Look at your log files:
When a system is working, data will appear in events.log, in summary form.
When it’s not working, the reasoning can be derived from openhab.log, or your custom mios.log.
- after manually Switching a Z-Wave switch/dimmer attached to Vera (assuming you have HAIL/Instant Status type switches), validate that you see that switch activated.
Here’s an example of the various elements. In this case, I have a Dimmer that’s also paired/associated with a 4x Button scene controller. Changing the Light/Dimmer status is triggering the [Leviton] Scene Controller to be tweaked by Vera/Z-Wave (for the LED status updates)
grep Family /var/log/syslog/events.log
2016-05-04 23:02:31 - FamilyControllerDeviceStatus state updated to PENDING
2016-05-04 23:02:31 - FamilyControllerLastUpdate state updated to Uninitialized
2016-05-04 23:02:32 - FamilyControllerDeviceStatus state updated to NONE
2016-05-04 23:02:32 - FamilyControllerLastUpdate state updated to 2016-05-04T23:02:32
2016-05-04 23:02:32 - FamilyControllerId state updated to 144
2016-05-04 23:23:34 - FamilyControllerDeviceStatus state updated to PENDING
2016-05-04 23:23:34 - FamilyControllerLastUpdate state updated to Uninitialized
2016-05-04 23:23:34 - FamilyControllerId state updated to 144
2016-05-04 23:23:41 - FamilyControllerDeviceStatus state updated to NONE
2016-05-04 23:23:41 - FamilyControllerLastUpdate state updated to 2016-05-04T23:23:42
2016-05-04 23:23:41 - FamilyControllerId state updated to 144
2016-05-04 23:24:47 - FamilyTheatreLightsStatus state updated to ON
2016-05-04 23:24:47 - FamilyTheatreLightsLoadLevelStatus state updated to 100
2016-05-04 23:24:47 - FamilyTheatreLightsId state updated to 13
2016-05-04 23:24:47 - FamilyControllerId state updated to 144
2016-05-04 23:25:05 - FamilyTheatreLightsLoadLevelStatus state updated to 78
2016-05-04 23:25:05 - FamilyTheatreLightsId state updated to 13
2016-05-04 23:25:05 - FamilyControllerId state updated to 144
2016-05-04 23:25:11 - FamilyTheatreLightsStatus state updated to OFF
2016-05-04 23:25:11 - FamilyTheatreLightsLoadLevelStatus state updated to 0
2016-05-04 23:25:11 - FamilyTheatreLightsId state updated to 13
- after manually opening a Contact sensor (opening Door or Window), and see that it’s showing up correctly in the logs.
Here’s some sample output from my system using
grep DoorZone /var/log/syslog/events.log
I have a TON of contact sensors, since my Paradox Alarm system hangs off Vera. These values are all being auto-generated by Vera, and bridged over the openHAB 1.8 MiOS Binding:
2016-05-04 20:48:11 - FrontDoorZoneTripped state updated to OPEN
2016-05-04 20:48:11 - FrontDoorZoneId state updated to 131
2016-05-04 20:48:11 - FrontDoorZoneLastTrip state updated to 2016-05-04T20:48:16
2016-05-04 20:48:11 - FrontDoorZoneLastUpdate state updated to 2016-05-04T20:48:16
2016-05-04 20:48:11 - FrontDoorZoneId state updated to 131
2016-05-04 20:48:23 - LetterboxDoorZoneTripped state updated to OPEN
2016-05-04 20:48:23 - LetterboxDoorZoneLastTrip state updated to 2016-05-04T20:48:29
2016-05-04 20:48:23 - LetterboxDoorZoneLastUpdate state updated to 2016-05-04T20:48:29
2016-05-04 20:48:23 - LetterboxDoorZoneId state updated to 438
2016-05-04 20:48:26 - LetterboxDoorZoneTripped state updated to CLOSED
2016-05-04 20:48:26 - LetterboxDoorZoneLastUpdate state updated to 2016-05-04T20:48:31
2016-05-04 20:48:26 - LetterboxDoorZoneId state updated to 438
2016-05-04 20:48:51 - FrontDoorZoneTripped state updated to CLOSED
2016-05-04 20:48:51 - FrontDoorZoneLastUpdate state updated to 2016-05-04T20:48:56
2016-05-04 20:48:51 - FrontDoorZoneId state updated to 131
[quote]Contact BackDoorSensorTripped2 “Back Door Sensor Tripped2 [MAP(door.map):%s]” (GDevices,GRoom1) {mios=“unit:house,device:122/service/urn:micasaverde-com:serviceId:SecuritySensor1/Tripped”}
[/quote]
door.map is a custom addition. If you’ve not created door.map, and put it into the configurations/transform directory, then it’s going to be unpredictable the behavior that the UI layer gives.
Without this UI MAP, and with the default/generated output from the MiOS Item generator, you’ll see values of open and closed, along with a “special” (state-sensitive) icon.
Here’s (roughly) what the Item Generator would have built:
Contact EXTGardenBackMotionZoneTripped "EXT Garden Back Motion (Zone 34) [MAP(en.map):%s]" (GContact,GMotion,GPersist) {mios="unit:house,device:444/service/SecuritySensor1/Tripped"}
*en.map ships by default, in the configurations/transform directory, and can be used as an example of how to create something like door.map
Given the tweaks, I’d recommend making a backup copy of your Items file, and performing a regen to get a clean MiOS Item Generator. Let’s get that working before making changes - I think that’ll avoid a lot of heartache, it’s actually the motivation for writing the tool, as a number of people struggled to get working files (and one typo can silently prevent 1/2 the config file from loading)
Once the basics are functional with no errors (see tests above), we then move onto a _basic_Sitemap that lets you see (Text, Dates, Status, Contacts) and change (Buttons, Scene-Buttons) the values.
openHAB 1.x does require a degree of patience to get going, and the best advise I can give is to get it working in increments. OH 1.x config can be edited using the openHAB Designer, which adds a structured editor, or the Text files (as you’ve been doing). I live in a text editor (vi) so the latter is more familiar, faster and at the same time much more error prone (no safety net)
Errors tend to build atop each other, so when I find a few obvious ones, I tend to stop, wait for those to be corrected, and then get new logs/config to validate the next layer.
Source code reviews are similar 
In some case, when I find tweaks/customizations in a number of different areas, the overall review progress slows markedly.
Here’s the general progression I’ve seen people be successful at when learning to work with openHAB and Vera, validating at each step along the way:
- Generate a default MiOS Item generator output validate it per-above (no tweaking!)
- Create a super-simple Sitemap (see the Demo Sitemap for common Item visualizations) and keep it to one Text, one Contact, one Switch (for now)
- Round out the Sitemap file for your rooms, keep reloading it as you add to the file. It’s very brittle as a file format, so best to add-and-validate as you go with any additions here.
- Tweak any Item Labels to suit personal tastes
- Create a
MAP file, and stitch it in to the Presentation layer (label="..." on an Item)
- Create a Rule.
BTW: I’ve incorporated changes, based upon your experiences, into the MiOS Item generator tooling and Wiki pages. These should make it clearer how to avoid at least some of the issues you’ve run into along the way.
Everyone goes through the same teething problems with OH 1.x config, so it’s not a problem. I’m v.busy at work, so my responses will be sporadic… at best.
@TheKorn, thanks for all your assists in this thread, much appreciated! Your pointers on the MAP files sees on-point.
0=CLOSED
1=OPEN
undefined=unknown
Yup, exactly how it should look. It also should not be “saved” using a Windows editor - unless in pure/plain ASCII. By default Windows text-editors (Notepad, we’re looking at you) tend to put BOM characters at the beginning, for UTF-8 Character encoding, and that’ll screw up everything.
ie. The file will be present, but most likely wont load correctly into the MAP engine.
The steps listed below are an abridged version of the primary 
)
)