Try to install mios binding for few days without success

Hi all,

I am using OpenHab for my MQTT devices and Vera3 for my Zwave devices
I try to exchange information between OpenHab and my Vera3 controller.

Look really simple but obviously I missed somethings.

I have the “org.openhab.binding.mios-1.8.2.jar” and “org.openhab.action.mios-1.8.2.jar” are on my /opt/openhab/addons/

On my openhab.cgt I have “mios:house.host=192.168.1.55”

on my itens I have : Switch Appliance_Module “Appliance Module” (All) {mios=“unit:house,device:6/service/SwitchPower1/Status”}

on my maps I have: Switch item=Appliance_Module label=“Appliance_Module”

The debug show me this:
^Cpi@raspberrypi:/opt/openhab/addons $ sudo sh /opt/openhab/start_debug.sh | grep Mios
20:55:43.728 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘MiOSMemoryUsed (Type=NumberItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.741 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘MiOSMemoryAvailable (Type=NumberItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.749 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘MiOSMemoryCached (Type=NumberItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.758 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘MiOSMemoryBuffers (Type=NumberItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.766 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘MiOSCMHLastRebootLinux (Type=StringItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.775 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘MiOSMemoryUsedString (Type=StringItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.785 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘Appliance_Module (Type=SwitchItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.808 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘HallLightAsSwitch (Type=NumberItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.821 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item ‘MsgLevelMS_Alert (Type=SwitchItem, State=Uninitialized)’ with ‘MiosBindingProviderImpl’ reader.
20:55:43.979 [DEBUG] [.a.mios.internal.MiosActivator:33 ] - MiOS Action has been started.
20:55:43.990 [DEBUG] [a.m.internal.MiosActionService:77 ] - MiOS setMiosActionProvider called
20:55:43.993 [DEBUG] [a.m.internal.MiosActionService:38 ] - MiOS action service activated
20:55:45.171 [DEBUG] [riptExtensionClassNameProvider:63 ] - Script actions have changed: AudioActionService, PingActionService, ExecActionService, TransformationActionService, MailActionService, HTTPActionService, MiosActionService,

I check, check, check each Evening for few days and I cannot find the solution.

What did I missed?
What do I need to check?

Thanks

Did you install the required MAP files ?

1 Like

Typo? It needs to be in the openhab.cfg file.

If you’re using the apt-get method for installation, they’ll be somewhere like:

/usr/share/openhab/addons/org.openhab.action.mios-1.8.2.jar
/usr/share/openhab/addons/org.openhab.binding.mios-1.8.2.jar

Looks like you’re using a manual install type. The bindings are running, since the logs are showing (roughly) correctly. At some point it may be worthwhile moving to the apt-get style install, for ease of patching (etc)

20:55:43.728 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'MiOSMemoryUsed (Type=NumberItem, State=Uninitialized)' with 'MiosBindingProviderImpl' reader.
20:55:43.741 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'MiOSMemoryAvailable (Type=NumberItem, State=Uninitialized)' with 'MiosBindingProviderImpl' reader.
20:55:43.749 [DEBUG] [i.internal.GenericItemProvider:341 ] - Start processing binding configuration of Item 'MiOSMemoryCached (Type=NumberItem, State=Uninitialized)' with 'MiosBindingProviderImpl' reader.

Based upon the Item names used in the output, it looks like you hand-built the Items file. You’ll want to publish a complete copy, since it’s easy to make typo’s that prevent parts of it from loading.

When this happens, it’s very subtle and even using the TRACE level logs it’ll be difficult to catch the problem, at least not without close inspection.

My recommendation is to use the MiOS Item Generator to produce the Items file. It’ll give you a clean starting point, and help you skip a chunk of the diagnostics process - as we’ll know that the Items file is in the correct format.

If you continue to have problems after that, post a link with your Items & Sitemap files, along with the openhab.log and events.log files.

This is in your Sitemap file, or have you configured it to a MAP file?

Yes I have the Map installed and it is working for other Items.

for the openhab.cfg, it it was a typo.

I forgot to say that I tried the MIOS Item Generator but I got the message "Failed to load, Check IP Address supplied"
The Raspberry and the Vera3 are on the same network and connect to the same switch and I can ping the Vera3 from the Raspberry

Look like the Vera3 do not allow Mios connection.

That can mean a few things:

a) That IP Address isn’t a Vera Unit
b) The Vera Unit it taking too long to respond (eg. under heavy load)
c) The Vera has been locked down for local access, it’s only accessible to their Hosting service.
d) The Vera has had a password added to it’s local service.

The miosLoad.sh script is really just this command:

curl --max-time 15 \
     --output ${MIOS_OUT} \
     --verbose \
     --silent "http://${MIOS_IP}:49451/data_request?id=user_data&output_format=xml"

In the above, I’ve added the --verbose option to it, and if you do the same then it’ll report more output about what it’s doing/seeing.

If you post that, in it’s entirety, that might give us more information.

Here’s a sample of mine, after adding the --verbose option manually to miosLoad.sh and then running it.

mark$ ./miosLoad.sh 10.3.1.15
Loading MiOS Unit Metadata from 10.3.1.15...
*   Trying 10.3.1.15...
* Connected to 10.3.1.15 (10.3.1.15) port 49451 (#0)
> GET /data_request?id=user_data&output_format=xml HTTP/1.1
> Host: 10.3.1.15:49451
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< CONTENT-LENGTH: 900922
< CONTENT-TYPE: xml
< DATE: Wed, 11 May 2016 13:55:13 GMT
< LAST-MODIFIED: Wed, 11 May 2016 13:55:13 GMT
< SERVER: Linux/2.6.37.1, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
< X-User-Agent: redsonic
< CONNECTION: close
< 
{ [4380 bytes data]
* Closing connection 0
Metadata Loaded into user_data.xml!

pi@raspberrypi:/opt/openhab $ sudo sh miosLoad.sh 10.1.1.55
Loading MiOS Unit Metadata from 10.1.1.55…

  • Hostname was NOT found in DNS cache
  • Trying 10.1.1.55…
  • connect to 10.1.1.55 port 49451 failed: Connection refused
  • Failed to connect to 10.1.1.55 port 49451: Connection refused
  • Closing connection 0
    miosLoad.sh: 18: [: 7: unexpected operator
    Failed to load, Check IP Address supplied.

The Raspberry is on 10.32.1.50
On the Vera3 the Firewall is deactivate.

Are you using a 10.x.x.x/24 Network?

If not, can you describe all the Network components sitting between the RPi and the Vera? It looks like something in your deployment is blocking the 49451 Port (used for MiOS Communications).

There’s a newer variant of that port (3480) that the script can be changed to but normally both are available/exposed by a Vera in a standard configuration. You can tweak the script to use that port instead of 49451 as an extra test (but we need to get to the bottom of what’s blocking comms in your environment.

Yes, it is a 10.x.x.x/24 Network.
I will test the 3480 tonight

Thanks to help me this.

I managed to get the MIOS Item Generator working on port 49451 (the “-verbose” help a lot for the trouble shooting).

I had to connect the RPI (on DHCP CLient ) to one of one Lan port on the Vera3.
Using the Vera Lan network the moisLoad.sh is working.

Look like the problem is when I have the Vera3 connected to the PRI using the Wan port on the Vera3.
Just to be sure I isolate my Home Lan network (no more Route or Firewall) and it was still not working using the Vera3 Wan port.

The Firewall on the Vera3 is still Disable.
so not I just need to find why the Vera do not allow connection from the Wan port but allow from the Lan Port.

Not yet fix but we are moving slowly…

You should be able to “ping” Vera from the RPi, over the WAN interface, since Vera responds to ICMP’s. If that doesn’t work then the issue is localized to the Network config itself.

Given you’re on a huge subnet, it would be worthwhile double-checking the broadcast address and general net-config. I’ve seen large nets like that seriously misbehave when the NetMask gets out of whack (that, and the issues if V interfering with DHCP, but that’s another story)

I too had issues on port 49451 so I changed script to port 3480. It did seems to generate items however I have never been able to get it to work after many hours of trying

I am happy to say log:display led to me finding a ’ in a device name and that prevent the .items file from loading