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
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:
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.
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.
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)