[quote=“nutcracker, post:5, topic:185626”]guessed, thank you.
I tried both the examples you’ve provided but no luck. In fact, I can’t see any evidence of device 46 appearing in the list of ‘not bound’ devices that are listed.[/quote]
Do you see it in the list of BOUND (case-sensitive) ones? If not, then you may not have the right logging level set (typically done by running the start_debug.xxx script, instead of start.xxx AND having the corresponding log file set to have TRACE level MiOS Logs (which isn’t the default for any of the logback*.xml files)
All Vera ServiceId/Variable values should appear in either the “[tt]BOUND[/tt]”, or “[tt]NOT BOUND[/tt]” lists.
What I do see is this - could this cause the processing of devices to stop?
2015-01-26 17:23:53.180 [TRACE] [.o.b.mios.internal.MiosBinding] - internalPropertyUpdate: NOT BOUND {mios="unit:house,device:30/service/urn:upnp-org:serviceId:IPhoneLocator1/RootPrefix"}, value=(*)
2015-01-26 17:23:53.180 [TRACE] [.o.b.mios.internal.MiosBinding] - internalPropertyUpdate: NOT BOUND {mios="unit:house,device:30/service/urn:upnp-org:serviceId:IPhoneLocator1/LocationExtraInfo"}, value=GPS:50:false
2015-01-26 17:23:53.180 [DEBUG] [b.m.internal.MiosUnitConnector] - run: Exception Error occurred fetching content: For input string: "1422179878.218"
java.lang.NumberFormatException: For input string: "1422179878.218"
at java.lang.NumberFormatException.forInputString(Unknown Source) ~[na:1.8.0_31]
at java.lang.Integer.parseInt(Unknown Source) ~[na:1.8.0_31]
at java.lang.Integer.parseInt(Unknown Source) ~[na:1.8.0_31]
at org.openhab.binding.mios.internal.MiosUnitConnector$LongPoll.fixTimestamp(MiosUnitConnector.java:437) ~[na:na]
at org.openhab.binding.mios.internal.MiosUnitConnector$LongPoll.processDevices(MiosUnitConnector.java:580) ~[na:na]
at org.openhab.binding.mios.internal.MiosUnitConnector$LongPoll.processResponse(MiosUnitConnector.java:673) ~[na:na]
at org.openhab.binding.mios.internal.MiosUnitConnector$LongPoll.run(MiosUnitConnector.java:743) ~[na:na]
at java.lang.Thread.run(Unknown Source) [na:1.8.0_31]
It’s quite possible that the code needs to be more guarded when these conversions can’t take place.
From the above stack, it looks like the iPhone locator Plugin has a bug in it. Epoch timestamps in Vera, like the one listed above, are supposed to be a Long-value, not a Float-value.
For some reason, the iPhone Locator Plugin is putting a float into one of the internal Epoch timestamp fields.
If you’re running the 1.7.x MiOS Binding codebase, change the Item to use “String” instead of “DateTime” and that part will load. In the 1.7.x codebase, I only convert IF you’ve bound it to a DateTime Item-type OR if it’s one of the internal “System” fields supplied only by Vera (TimeStamp, Timestamp, DeviceSync, LoadTime, zwave_heal, time_created)
Great stuff!