openHAB 2.0 binding
-
@TimO yes I think it works with manual bindins (several discussions mention it) but I meant using paper ui as you do here
-
Well if I add a door sensor and just enter some random node id/child Id it shows up as online. I never managed to add any sensor automatically even if I start the search process and resetting any sensors.
But the problem is that I can't get any reaction from the switch. I have tried connecting a button to pin 3 and also tried just connecting a cable from pin 3 to gnd. But no reaction whatever I do.
-
@Qu3Uk : Fixed the error. The sensors were initialized before the bridge was up.
@Cliff-Karlsson: The status of a thing in OH is not reliable and I'm yet not sure how to make it reliable because the connection between sensor and gateway is stateless, so a sensor maybe is online even if it only transmits one time per day.
In your case: what is the output of the "start_debug.sh"? Are there messages from the MySensors Gateway logged?
-
Nice work!
Did anyone try the binding with FakeMySensors?
http://forum.mysensors.org/topic/1648/test-your-home-made-controller-with-fakemysensors
-
after OH2 restart I got "UNINITIALIZED - HANDLER_INITIALIZING_ERROR" for all already existing sensors. If I add a new sensors it works until OH2 restart
-
on thing removing:
2015-08-21 19:40:36 [DEBUG] [.c.thing.internal.ThingManager:174 ] - Asking handler of thing 'mysensors:temperature:8da0bd23:Temperature_87_1' to handle its removal.
2015-08-21 19:40:36 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:temperature:8da0bd23:Temperature_87_1' updated: REMOVING
2015-08-21 19:40:36 [ERROR] [.c.thing.internal.ThingManager:178 ] - The ItemHandler caused an exception while handling the removal of its thingjava.lang.NullPointerException: null
at org.eclipse.smarthome.core.thing.internal.ThingManager$1.statusUpdated(ThingManager.java:176)
at org.eclipse.smarthome.core.thing.internal.ThingManager.thingRemoving(ThingManager.java:361)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.notifyTrackers(ThingRegistryImpl.java:193)
at org.eclipse.smarthome.core.thing.internal.ThingRegistryImpl.remove(ThingRegistryImpl.java:89)
at org.eclipse.smarthome.core.thing.setup.ThingSetupManager.removeThing(ThingSetupManager.java:442)
at org.eclipse.smarthome.io.rest.core.thing.setup.ThingSetupManagerResource.removeThing(ThingSetupManagerResource.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
-
@ZoTyA said:
after OH2 restart I got "UNINITIALIZED - HANDLER_INITIALIZING_ERROR" for all already existing sensors. If I add a new sensors it works until OH2 restart
This should be fixed but I don't think @Tim0 has released the fix yet? Might be wrong.
-
I'm pretty sure this time it is a bug in OH2, because my code works sometimes.
I've found a workaround and got 10/10 clean starts of OH2 and reinitializations of the configured things.Please let me know, if the error occures again!
Thanks for testing!!
-
How do I keep openhab2 updated after installing?
-
What do you want to keep updated? The OH2 runtime? The binding?
I update the link of the binding (jar-file) in the first post here whenever I add or fix something. You only have to switch this jar file in your installation. In the current alpha phase it is an good idea to delete the userdata folder, but with that you will lose all already discovered and added things. I have configured all things/items that should survive a deletion of the userdata in the thing.conf, items.conf etc.
For the future I plan to make a pull request so that the mysensors binding will be a fixed part of OH2, but I want to ensure its stability before I do so. Additionally there are some features I would like to add before making a pull request.
-
@Qu3Uk said:
@ZoTyA said:
after OH2 restart I got "UNINITIALIZED - HANDLER_INITIALIZING_ERROR" for all already existing sensors. If I add a new sensors it works until OH2 restart
This should be fixed but I don't think @Tim0 has released the fix yet? Might be wrong.
Confirmed - it is fixed.
Thanks
-
@TimO Slightly off topic but am I right in thinking even with discovered things you still have to manually create an item for the thing in the item.conf for stuff like rules to work?
-
@Qu3Uk I asked a similar question about persistence on the OH2 forum and the response was you could set up a group and configure persistence for it. Then as the new items are dynamically found they just need to be added to the group without adding them to the config files. Possibly the same thing would work for rules.
-
@Qu3Uk Looks like they are adding some support for this: https://community.openhab.org/t/rules-allowing-regexp-for-items-and-catching-individual-items-in-a-group/2165
-
@TimO I'm having difficulty with the mysensors binding and the zwave binding on OH2 startup. If both bindings are present, then mysensors gets loaded first (port=/dev/ttyS2) and then zwave tries to load (port=/dev/ttyUSB0) however it reports that it's serial port is not present. If I remove the mysensors binding jar file from addons and then start OH2, the zwave binding connects to its serial port correctly and works fine. I can then mv the mysensors binding back into addons and it will get loaded and bind correctly to it's serial port. I've tried to turn the logging up to debug and not got anything more from the bindings to tell me what's happening. any help is appreciated. thanks.
-
@BenCranston : Thanks for the bug report! You're right I'm able to reproduce this error. The zwave and mysensors binding both use the same library (gnu.io) to access serial ports.
-
@TimO I'm beginning to think this might be platform specific to the gnu.io library and manifest on ARM architectures. I moved my OH2 installation over to my Mac and "Viola!" both services started working without an issue. Are you on an ARM platform as well? Initially I was running the MySensors gateway off of a GPIO serial port on my Pi. As part of working this I moved the gateway to an FTDI USB connection, so both devices were /dev/ttyUSB[01]. That didn't change the behavior and they still failed to co-exist from boot. I'm going to take a look at the gnu.io RXTX stuff and see if I can find a lead there... I'm not a java programmer, so this should be fun.
-
@TimO It looks like someone else ran into the same issue trying to do z-wave and enocean, both being serial connections. The discussion over on the community at openhab.org is here: https://community.openhab.org/t/serial-ports-issue/2516
I wonder if that sheds any further lights on the issue. They did get a fix implemented in the EnOcean binding to play nice with the zwave binding.
-
@BenCranston : Thanks for looking further into the problem. I was able to reproduce the problem on a x86 architecture.
I've looked into the fix for insteon and I'm not sure if that helps, because I don't use the updateProperties() method that is fixed.I don't know zwave, so to be sure: I've changed:
port=/dev/pts/1in zwave.cfg. Is that correct?
(I've running a serial emulation on /dev/pts/1).
-
@TimO : Yes sir, that's the config step to tell the zwave binding where it's serial port is. The rest is done via files, or the habmin interface.
-
Hi @TimO
I have a ESP8266 as Ethernet GW and a Nano with a S_HUM, S_TEMP and a S_LIGHT_LEVEL.
I follow as described steps and the S_TEMP sensor is updated almost immediately, the S_HUM takes some minutes and the S_LIGHT_LEVEL is never updated.Can you take a look please?
Launching the openHAB runtime... Listening for transport dt_socket at address: 8001 2015-09-26 11:42:26 [DEBUG] [s.m.i.r.i.ItemRuntimeActivator:23 ] - Registered 'item' configuration parser 2015-09-26 11:42:26 [INFO ] [uartz.impl.StdSchedulerFactory:1184 ] - Using default implementation for ThreadExecutor 2015-09-26 11:42:26 [INFO ] [rtz.core.SchedulerSignalerImpl:61 ] - Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl 2015-09-26 11:42:26 [INFO ] [rg.quartz.core.QuartzScheduler:240 ] - Quartz Scheduler v.2.2.1 created. 2015-09-26 11:42:26 [INFO ] [org.quartz.simpl.RAMJobStore :155 ] - RAMJobStore initialized. 2015-09-26 11:42:26 [INFO ] [rg.quartz.core.QuartzScheduler:305 ] - Scheduler meta-data: Quartz Scheduler (v2.2.1) 'openHAB-job-scheduler' with instanceId 'NON_CLUSTERED' Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally. NOT STARTED. Currently in standby mode. Number of jobs executed: 0 Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 2 threads. Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered. 2015-09-26 11:42:26 [INFO ] [uartz.impl.StdSchedulerFactory:1339 ] - Quartz scheduler 'openHAB-job-scheduler' initialized from specified file: './runtime/etc/quartz.properties' 2015-09-26 11:42:26 [INFO ] [uartz.impl.StdSchedulerFactory:1343 ] - Quartz scheduler version: 2.2.1 2015-09-26 11:42:26 [DEBUG] [.i.PersistenceRuntimeActivator:23 ] - Registered 'persistence' configuration parser 2015-09-26 11:42:26 [DEBUG] [s.m.r.r.i.RuleRuntimeActivator:35 ] - Registered 'rule' configuration parser 2015-09-26 11:42:26 [DEBUG] [m.s.r.i.ScriptRuntimeActivator:22 ] - Registered 'script' configuration parser 2015-09-26 11:42:26 [DEBUG] [.s.r.i.SitemapRuntimeActivator:23 ] - Registered 'sitemap' configuration parser 2015-09-26 11:42:26 [DEBUG] [.m.t.r.i.ThingRuntimeActivator:23 ] - Registered 'thing' configuration parser osgi> 2015-09-26 11:42:27 [WARN ] [.j.s.handler.RequestLogHandler:137 ] - !RequestLog 2015-09-26 11:42:27 [DEBUG] [.c.d.internal.ConfigDispatcher:222 ] - Processing config file 'services.cfg' 2015-09-26 11:42:27 [DEBUG] [.c.d.internal.ConfigDispatcher:222 ] - Processing config file 'runtime.cfg' 2015-09-26 11:42:28 [DEBUG] [.s.core.internal.CoreActivator:30 ] - Core bundle has been started. 2015-09-26 11:42:28 [DEBUG] [.e.s.c.a.i.AutoUpdateActivator:29 ] - AutoUpdate binding has been started. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:118 ] - Reading the XML document '/ESH-INF/binding/binding.xml' in module 'org.openhab.binding.mysensors'... 2015-09-26 11:42:28 [DEBUG] [o.e.s.c.s.i.SchedulerActivator:34 ] - Scheduler has been started. 2015-09-26 11:42:28 [INFO ] [rg.quartz.core.QuartzScheduler:575 ] - Scheduler openHAB-job-scheduler_$_NON_CLUSTERED started. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:159 ] - Create an empty XmlDocumentProvider for the module 'org.openhab.binding.mysensors'. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:118 ] - Reading the XML document '/ESH-INF/thing/channels.xml' in module 'org.openhab.binding.mysensors'... 2015-09-26 11:42:28 [DEBUG] [.c.t.i.TransformationActivator:34 ] - Transformation Service has been started. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:159 ] - Create an empty XmlDocumentProvider for the module 'org.openhab.binding.mysensors'. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:118 ] - Reading the XML document '/ESH-INF/thing/thing-types.xml' in module 'org.openhab.binding.mysensors'... 2015-09-26 11:42:28 [DEBUG] [.e.s.i.m.i.MultimediaActivator:32 ] - Multimedia I/O bundle has been started. 2015-09-26 11:42:28 [DEBUG] [c.x.o.XmlDocumentBundleTracker:118 ] - Reading the XML document '/ESH-INF/thing/bridges.xml' in module 'org.openhab.binding.mysensors'... 2015-09-26 11:42:28 [DEBUG] [io.rest.internal.RESTActivator:32 ] - REST API has been started. 2015-09-26 11:42:28 [DEBUG] [s.i.t.m.internal.MDNSActivator:27 ] - mDNS service has been started. 2015-09-26 11:42:28 [DEBUG] [.i.t.m.internal.MDNSClientImpl:37 ] - mDNS service has been started 2015-09-26 11:42:28 [DEBUG] [i.t.m.internal.MDNSServiceImpl:85 ] - Registering new service _openhab-server._tcp.local. at port 8080 2015-09-26 11:42:28 [DEBUG] [i.t.m.internal.MDNSServiceImpl:85 ] - Registering new service _openhab-server-ssl._tcp.local. at port 8443 2015-09-26 11:42:28 [DEBUG] [.i.r.sse.internal.SseActivator:46 ] - SSE API - SseFeature registered. 2015-09-26 11:42:28 [DEBUG] [.i.r.sse.internal.SseActivator:55 ] - SSE API has been started. 2015-09-26 11:42:28 [DEBUG] [.io.transport.mqtt.MqttService:118 ] - Starting MQTT Service... 2015-09-26 11:42:28 [DEBUG] [.s.s.mapdb.MapDbStorageService:50 ] - Opened MapDB file at 'D:\Downloads\openhab2\.\userdata\mapdb\storage.mapdb'. 2015-09-26 11:42:28 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.core.items.ManagedItemProvider' has been added. 2015-09-26 11:42:28 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.core.thing.ManagedThingProvider' has been added. 2015-09-26 11:42:28 [DEBUG] [.core.common.ThreadPoolManager:141 ] - Created scheduled thread pool 'discovery' of size 3 2015-09-26 11:42:28 [DEBUG] [.c.thing.internal.ThingManager:549 ] - Thing handler factory 'MySensorsHandlerFactory' added 2015-09-26 11:42:28 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.core.thing.link.ManagedItemChannelLinkProvider' has been added. 2015-09-26 11:42:28 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.core.thing.link.ManagedItemThingLinkProvider' has been added. 2015-09-26 11:42:28 [DEBUG] [ui.internal.chart.ChartServlet:122 ] - Starting up chart servlet at /chart 2015-09-26 11:42:28 [DEBUG] [u.i.chart.DefaultChartProvider:97 ] - Starting up default chart provider. 2015-09-26 11:42:28 [DEBUG] [o.e.s.u.c.i.servlet.CmdServlet:56 ] - Starting up CMD servlet at /classicui/CMD 2015-09-26 11:42:28 [DEBUG] [s.ui.icon.internal.IconServlet:76 ] - Starting up icon servlet at /icon 2015-09-26 11:42:28 [INFO ] [ui.internal.servlet.PaperUIApp:31 ] - Started Paper UI at /ui 2015-09-26 11:42:29 [DEBUG] [e.s.i.t.upnp.UpnpIOServiceImpl:152 ] - Starting UPnP IO service... 2015-09-26 11:42:29 [INFO ] [.u.d.internal.DashboardService:55 ] - Started dashboard at /start 2015-09-26 11:42:29 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.model.item.internal.GenericItemProvider' has been added. 2015-09-26 11:42:29 [INFO ] [rg.quartz.core.QuartzScheduler:2311 ] - JobFactory set to: org.eclipse.smarthome.model.rule.runtime.internal.engine.GuiceAwareJobFactory@1762bd77 2015-09-26 11:42:29 [DEBUG] [.m.r.r.i.engine.RuleEngineImpl:96 ] - Started rule engine 2015-09-26 11:42:29 [INFO ] [.s.u.c.i.servlet.WebAppServlet:85 ] - Started Classic UI at /classicui/app 2015-09-26 11:42:29 [DEBUG] [e.s.m.t.i.GenericThingProvider:696 ] - ThingHandlerFactory added org.openhab.binding.mysensors.internal.MySensorsHandlerFactory@25ceff93 2015-09-26 11:42:29 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.model.thing.internal.GenericThingProvider' has been added. 2015-09-26 11:42:29 [DEBUG] [.c.c.registry.AbstractRegistry:190 ] - Provider 'org.eclipse.smarthome.model.thing.internal.GenericItemChannelLinkProvider' has been added. 2015-09-26 11:42:29 [DEBUG] [ui.internal.proxy.ProxyServlet:94 ] - Starting up proxy servlet at /proxy 2015-09-26 11:42:29 [INFO ] [.o.core.internal.CoreActivator:41 ] - openHAB runtime has been started (v2.0.0, build 201509240103). 2015-09-26 11:42:29 [DEBUG] [.o.core.internal.CoreActivator:47 ] - Startup took 6896 ms 2015-09-26 11:42:36 [DEBUG] [io.rest.core.item.ItemResource:127 ] - Received HTTP GET request at 'items' 2015-09-26 11:42:49 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element home_group_daef4dc3 to ManagedItemProvider. 2015-09-26 11:42:49 [DEBUG] [.core.common.ThreadPoolManager:171 ] - Created thread pool 'safeCall' with size 3-10 2015-09-26 11:42:49 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'home_group_daef4dc3' has been added. 2015-09-26 11:43:31 [DEBUG] [.c.thing.internal.ThingManager:363 ] - Thing 'mysensors:bridge-eth:c27764bd' is tracked by ThingManager. 2015-09-26 11:43:31 [INFO ] [marthome.event.ThingAddedEvent:43 ] - Thing 'mysensors:bridge-eth:c27764bd' has been added. 2015-09-26 11:43:31 [DEBUG] [.c.thing.internal.ThingManager:487 ] - Calling registerHandler handler for thing 'mysensors:bridge-eth:c27764bd' at 'org.openhab.binding.mysensors.intern erFactory@25ceff93'. 2015-09-26 11:43:31 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:bridge-eth:c27764bd' updated: INITIALIZING 2015-09-26 11:43:31 [DEBUG] [.core.common.ThreadPoolManager:141 ] - Created scheduled thread pool 'thingHandler' of size 3 2015-09-26 11:43:31 [DEBUG] [o.b.m.h.MySensorsBridgeHandler:58 ] - Initialization of the MySensors Bridge 2015-09-26 11:43:31 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 192.168.0.17 to field 'ipAddress' in configuration class org.openhab.binding.mysensors.conf eConfiguration 2015-09-26 11:43:31 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 5003 to field 'tcpPort' in configuration class org.openhab.binding.mysensors.config.MySenso tion 2015-09-26 11:43:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:40 ] - Connecting to bridge ... 2015-09-26 11:43:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:56 ] - Connection to ethernet gateway successful! 2015-09-26 11:43:31 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:bridge-eth:c27764bd' updated: ONLINE 2015-09-26 11:43:31 [DEBUG] [.c.thing.internal.ThingManager:84 ] - Thing handler for thing 'mysensors:bridge-eth:c27764bd' added. 2015-09-26 11:43:31 [DEBUG] [.c.thing.internal.ThingManager:252 ] - Assigning handler for thing 'mysensors:bridge-eth:c27764bd'. 2015-09-26 11:43:31 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors:bridge-eth:c27764bd to ManagedThingProvider. 2015-09-26 11:43:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 0;0;3;0;14;Gateway startup complete. 2015-09-26 11:43:32 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_bridge_eth_c27764bd to ManagedItemProvider. 2015-09-26 11:43:32 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_bridge_eth_c27764bd' has been added. 2015-09-26 11:43:32 [DEBUG] [.c.t.internal.ThingLinkManager:328 ] - Assigning linked group item 'mysensors_bridge_eth_c27764bd' to thing 'mysensors:bridge-eth:c27764bd'. 2015-09-26 11:43:32 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_bridge_eth_c27764bd -> mysensors:bridge-eth:c27764bd to ManagedItemThingLinkProvider. 2015-09-26 11:43:32 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:volt, myse nsors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, m vel]' on 'MySensorsDiscoveryService'... 2015-09-26 11:44:02 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;37 2015-09-26 11:44:14 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;38 2015-09-26 11:44:16 [DEBUG] [.c.thing.internal.ThingManager:363 ] - Thing 'mysensors:humidity:7d1da077' is tracked by ThingManager. 2015-09-26 11:44:16 [DEBUG] [.c.thing.internal.ThingManager:487 ] - Calling registerHandler handler for thing 'mysensors:humidity:7d1da077' at 'org.openhab.binding.mysensors.internal Factory@25ceff93'. 2015-09-26 11:44:16 [INFO ] [marthome.event.ThingAddedEvent:43 ] - Thing 'mysensors:humidity:7d1da077' has been added. 2015-09-26 11:44:16 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:humidity:7d1da077' updated: INITIALIZING 2015-09-26 11:44:16 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:humidity:7d1da077' updated: ONLINE 2015-09-26 11:44:16 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 1 to field 'nodeId' in configuration class org.openhab.binding.mysensors.config.MySensorsSe 2015-09-26 11:44:16 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 0 to field 'childId' in configuration class org.openhab.binding.mysensors.config.MySensorsS n 2015-09-26 11:44:16 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:humidity:7d1da077' updated: ONLINE 2015-09-26 11:44:16 [DEBUG] [.c.thing.internal.ThingManager:84 ] - Thing handler for thing 'mysensors:humidity:7d1da077' added. 2015-09-26 11:44:16 [DEBUG] [.c.thing.internal.ThingManager:252 ] - Assigning handler for thing 'mysensors:humidity:7d1da077'. 2015-09-26 11:44:16 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors:humidity:7d1da077 to ManagedThingProvider. 2015-09-26 11:44:16 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_humidity_7d1da077' has been added. 2015-09-26 11:44:16 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_humidity_7d1da077 to ManagedItemProvider. 2015-09-26 11:44:16 [DEBUG] [.c.t.internal.ThingLinkManager:328 ] - Assigning linked group item 'mysensors_humidity_7d1da077' to thing 'mysensors:humidity:7d1da077'. 2015-09-26 11:44:16 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_humidity_7d1da077 -> mysensors:humidity:7d1da077 to ManagedItemThingLinkProvider. 2015-09-26 11:44:17 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_humidity_7d1da077_hum to ManagedItemProvider. 2015-09-26 11:44:17 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_humidity_7d1da077_hum' has been added. 2015-09-26 11:44:17 [DEBUG] [.c.t.internal.ThingLinkManager:317 ] - Adding linked item 'mysensors_humidity_7d1da077_hum' to channel 'mysensors:humidity:7d1da077:hum'. 2015-09-26 11:44:17 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_humidity_7d1da077_hum -> mysensors:humidity:7d1da077:hum to ManagedItemChannelLinkProv 2015-09-26 11:44:17 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:volt, myse nsors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, m vel]' on 'MySensorsDiscoveryService'... 2015-09-26 11:44:27 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;37 2015-09-26 11:44:48 [DEBUG] [.c.thing.internal.ThingManager:363 ] - Thing 'mysensors:light-level:9e706943' is tracked by ThingManager. 2015-09-26 11:44:48 [INFO ] [marthome.event.ThingAddedEvent:43 ] - Thing 'mysensors:light-level:9e706943' has been added. 2015-09-26 11:44:48 [DEBUG] [.c.thing.internal.ThingManager:487 ] - Calling registerHandler handler for thing 'mysensors:light-level:9e706943' at 'org.openhab.binding.mysensors.inter lerFactory@25ceff93'. 2015-09-26 11:44:48 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 1 to field 'nodeId' in configuration class org.openhab.binding.mysensors.config.MySensorsSe 2015-09-26 11:44:48 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 2 to field 'childId' in configuration class org.openhab.binding.mysensors.config.MySensorsS n 2015-09-26 11:44:48 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:light-level:9e706943' updated: INITIALIZING 2015-09-26 11:44:48 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:light-level:9e706943' updated: ONLINE 2015-09-26 11:44:48 [DEBUG] [.c.thing.internal.ThingManager:84 ] - Thing handler for thing 'mysensors:light-level:9e706943' added. 2015-09-26 11:44:48 [DEBUG] [.c.thing.internal.ThingManager:252 ] - Assigning handler for thing 'mysensors:light-level:9e706943'. 2015-09-26 11:44:48 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:light-level:9e706943' updated: ONLINE 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors:light-level:9e706943 to ManagedThingProvider. 2015-09-26 11:44:48 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_light_level_9e706943' has been added. 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_light_level_9e706943 to ManagedItemProvider. 2015-09-26 11:44:48 [DEBUG] [.c.t.internal.ThingLinkManager:328 ] - Assigning linked group item 'mysensors_light_level_9e706943' to thing 'mysensors:light-level:9e706943'. 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_light_level_9e706943 -> mysensors:light-level:9e706943 to ManagedItemThingLinkProvider 2015-09-26 11:44:48 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_light_level_9e706943_light_level' has been added. 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_light_level_9e706943_light_level to ManagedItemProvider. 2015-09-26 11:44:48 [DEBUG] [.c.t.internal.ThingLinkManager:317 ] - Adding linked item 'mysensors_light_level_9e706943_light_level' to channel 'mysensors:light-level:9e706943:light-l 2015-09-26 11:44:48 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_light_level_9e706943_light_level -> mysensors:light-level:9e706943:light-level to Mana kProvider. 2015-09-26 11:44:48 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:volt, myse nsors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, m vel]' on 'MySensorsDiscoveryService'... 2015-09-26 11:45:05 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;36 2015-09-26 11:45:06 [INFO ] [marthome.event.ThingAddedEvent:43 ] - Thing 'mysensors:temperature:4a73d1fa' has been added. 2015-09-26 11:45:06 [DEBUG] [.c.thing.internal.ThingManager:363 ] - Thing 'mysensors:temperature:4a73d1fa' is tracked by ThingManager. 2015-09-26 11:45:06 [DEBUG] [.c.thing.internal.ThingManager:487 ] - Calling registerHandler handler for thing 'mysensors:temperature:4a73d1fa' at 'org.openhab.binding.mysensors.inter lerFactory@25ceff93'. 2015-09-26 11:45:06 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:temperature:4a73d1fa' updated: INITIALIZING 2015-09-26 11:45:06 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 1 to field 'nodeId' in configuration class org.openhab.binding.mysensors.config.MySensorsSe 2015-09-26 11:45:06 [DEBUG] [.e.s.config.core.Configuration:89 ] - Setting value (String) 1 to field 'childId' in configuration class org.openhab.binding.mysensors.config.MySensorsS n 2015-09-26 11:45:06 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:temperature:4a73d1fa' updated: ONLINE 2015-09-26 11:45:06 [DEBUG] [.c.thing.internal.ThingManager:84 ] - Thing handler for thing 'mysensors:temperature:4a73d1fa' added. 2015-09-26 11:45:06 [INFO ] [ome.event.ThingStatusInfoEvent:43 ] - mysensors:temperature:4a73d1fa' updated: ONLINE 2015-09-26 11:45:06 [DEBUG] [.c.thing.internal.ThingManager:252 ] - Assigning handler for thing 'mysensors:temperature:4a73d1fa'. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors:temperature:4a73d1fa to ManagedThingProvider. 2015-09-26 11:45:06 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_temperature_4a73d1fa' has been added. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_temperature_4a73d1fa to ManagedItemProvider. 2015-09-26 11:45:06 [DEBUG] [.c.t.internal.ThingLinkManager:328 ] - Assigning linked group item 'mysensors_temperature_4a73d1fa' to thing 'mysensors:temperature:4a73d1fa'. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_temperature_4a73d1fa -> mysensors:temperature:4a73d1fa to ManagedItemThingLinkProvider 2015-09-26 11:45:06 [INFO ] [smarthome.event.ItemAddedEvent:43 ] - Item 'mysensors_temperature_4a73d1fa_temp' has been added. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_temperature_4a73d1fa_temp to ManagedItemProvider. 2015-09-26 11:45:06 [DEBUG] [.c.t.internal.ThingLinkManager:317 ] - Adding linked item 'mysensors_temperature_4a73d1fa_temp' to channel 'mysensors:temperature:4a73d1fa:temp'. 2015-09-26 11:45:06 [DEBUG] [.c.c.r.AbstractManagedProvider:62 ] - Added new element mysensors_temperature_4a73d1fa_temp -> mysensors:temperature:4a73d1fa:temp to ManagedItemChannel 2015-09-26 11:45:06 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:volt, myse nsors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, m vel]' on 'MySensorsDiscoveryService'... 2015-09-26 11:45:14 [DEBUG] [io.rest.core.item.ItemResource:127 ] - Received HTTP GET request at 'items' 2015-09-26 11:45:40 [DEBUG] [io.rest.core.item.ItemResource:127 ] - Received HTTP GET request at 'items' 2015-09-26 11:46:00 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 0;0;3;0;14;Gateway startup complete. 2015-09-26 11:46:09 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;37 2015-09-26 11:46:21 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;38 2015-09-26 11:46:27 [DEBUG] [io.rest.core.item.ItemResource:127 ] - Received HTTP GET request at 'items' 2015-09-26 11:48:03 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.2 2015-09-26 11:48:03 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.2 2015-09-26 11:48:03 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;37 2015-09-26 11:49:32 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;36 2015-09-26 11:49:45 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.1 2015-09-26 11:49:45 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.1 2015-09-26 11:49:45 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:49:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;36 2015-09-26 11:50:10 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:50:23 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;45 2015-09-26 11:50:23 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 45 2015-09-26 11:50:23 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;34 2015-09-26 11:50:36 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:51:01 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;36 2015-09-26 11:51:14 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:52:05 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;34 2015-09-26 11:52:30 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:53:08 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 7 2015-09-26 11:53:21 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.2 2015-09-26 11:53:21 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.2 2015-09-26 11:53:21 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;33 2015-09-26 11:53:33 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 6 2015-09-26 11:53:46 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;33 2015-09-26 11:53:59 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;34 2015-09-26 11:56:06 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 5 2015-09-26 11:56:19 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;23.8 2015-09-26 11:56:19 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 23.8 2015-09-26 11:56:19 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;69 2015-09-26 11:56:19 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 69 2015-09-26 11:56:19 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 3 2015-09-26 11:56:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.5 2015-09-26 11:56:31 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.5 2015-09-26 11:56:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;81 2015-09-26 11:56:31 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 81 2015-09-26 11:56:31 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;32 2015-09-26 11:56:44 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.2 2015-09-26 11:56:44 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.2 2015-09-26 11:56:44 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;77 2015-09-26 11:56:44 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 77 2015-09-26 11:56:44 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2; 8 2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.4 2015-09-26 11:56:57 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.4 2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;65 2015-09-26 11:56:57 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 65 2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;34 2015-09-26 11:57:10 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;57 2015-09-26 11:57:10 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 57 2015-09-26 11:57:22 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;53 2015-09-26 11:57:22 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 53 2015-09-26 11:57:22 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;35 2015-09-26 11:57:35 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;50 2015-09-26 11:57:35 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 50 2015-09-26 11:57:35 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;19 2015-09-26 11:57:48 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;49 2015-09-26 11:57:48 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 49 2015-09-26 11:57:48 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;30 2015-09-26 11:58:00 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.3 2015-09-26 11:58:00 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.3 2015-09-26 11:58:00 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;48 2015-09-26 11:58:00 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 48 2015-09-26 11:58:00 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;26 2015-09-26 11:58:13 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;47 2015-09-26 11:58:13 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 47 2015-09-26 11:58:26 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;29 2015-09-26 11:58:39 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;46 2015-09-26 11:58:39 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 46 2015-09-26 11:58:39 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;27 2015-09-26 11:58:51 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.2 2015-09-26 11:59:09 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.3 2015-09-26 11:59:09 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.2 2015-09-26 11:59:09 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.3 2015-09-26 11:59:17 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;2;1;0;2;32Thank you
-
@BenCranston I finally found some time to further investigate this issue. Your guess according to the serial port issue was right. I've managed to "fix" the zwave binding using the code found while following the thread you mentioned.
I've created a modified version of the zwave binding:
org.openhab.binding.zwave-1.8.0-SNAPSHOT.jar
org.openhab.binding.mysensors-2.0.0-SNAPSHOT.jar
(I've not changed the mysensors binding, just added it for reference)Could you please test it? The binding is throwing messages and trying to contact the zwave gateway/stick:
2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = GetVersion (0x15), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 1 2015-10-13 08:32:44 [DEBUG] [WaveController$ZWaveSendThread:1228 ] - Took message from queue for sending. Queue length = 0 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ] - Assembled message buffer = 01 03 00 15 E9 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = MemoryGetId (0x20), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 1 2015-10-13 08:32:44 [DEBUG] [WaveController$ZWaveSendThread:1285 ] - NODE 255: Sending REQUEST Message = 01 03 00 15 E9 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = SerialApiGetCapabilities (0x07), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 2 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = SerialApiSetTimeouts (0x06), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 3 2015-10-13 08:32:44 [DEBUG] [i.p.s.GetSucNodeIdMessageClass:30 ] - Get SUC NodeID 2015-10-13 08:32:44 [DEBUG] [o.b.z.i.protocol.SerialMessage:109 ] - NODE 255: Creating empty message of class = GetSucNodeId (0x56), type = Request (0x00) 2015-10-13 08:32:44 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 4 2015-10-13 08:32:46 [DEBUG] [z.internal.ZWaveNetworkMonitor:315 ] - Network Monitor: Queue length is 4 - deferring network monitor functions. 2015-10-13 08:32:49 [ERROR] [WaveController$ZWaveSendThread:1326 ] - NODE 255: Timeout while sending message. Requeueing - 2 attempts left! 2015-10-13 08:32:49 [DEBUG] [b.z.i.protocol.ZWaveController:637 ] - Enqueueing message. Queue length = 5 2015-10-13 08:32:49 [DEBUG] [WaveController$ZWaveSendThread:1228 ] - Took message from queue for sending. Queue length = 4 2015-10-13 08:32:49 [DEBUG] [o.b.z.i.protocol.SerialMessage:233 ] - Assembled message buffer = 01 03 00 15 E9 2015-10-13 08:32:49 [DEBUG] [WaveController$ZWaveSendThread:1285 ] - NODE 255: Sending REQUEST Message = 01 03 00 15 E9
-
Hello @Daniel-Oliveira!
- S_Temp looks good:
2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;1;1;0;0;22.4 2015-09-26 11:56:57 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_temperature_4a73d1fa_temp updated to 22.4- S_HUM looks good too:
2015-09-26 11:56:57 [DEBUG] [b.m.p.ip.MySensorsIpConnection:72 ] - 1;0;1;0;1;65 2015-09-26 11:56:57 [INFO ] [smarthome.event.ItemStateEvent:43 ] - mysensors_humidity_7d1da077_hum updated to 65I can't see a reason why it should not update correctly. Could be a bug in the OH2 runtime? Does this bug persist with a current runtime?
- S_LIGHT_LEVEL
1;2;1;0;2;36With subtype 2 (V_STATUS) the binding is expecting 1 == ON or 2 == OFF.
For light level the binding is expecting V_PERCENTAGE.So a message like this should work:
1;2;1;0;3;36
-
Hi @TimO . Great work so far. I'd like to join in and extend your module with a lot more S_ and V_ types. Your Github repo code was updated 3 months ago. Do you want to push your commits so I can fork it?
Also another question: Do I need something special or is the default OpenHAB 2 IDE as described on the OpenHAB2 page enough to start?
-
Hi @SiLeX !
I would really appreciate your help!
My Repo is up to date, there are no open code changes. I've merged my Repo with the master/upstream, so OH2 too is up to date.The instructions here should work just fine, although I didn't set up my environment this way:
https://github.com/wishmoooop/openhab2/blob/master/docs/sources/development/ide.mdThere is only one step needed to activate the MySensors binding, it is an addition to the step 8 in the instructions:
- Click on "Run"
- Click on "Run Configurations ..."
- Select "OpenHAB_Runtime" on the left
- Switch to "Plug-Ins" on the right
- Search for "org.openhab.binding.mysensors" and mark it
(At this step I disable yahooweather and astro so they stop to annoy me with newly discovered locations)
If "strange" errors occure while testing code changes, delete the content of the "userdata" directory in "distribution/openhabhome".
-
@TimO said:
Search for "org.openhab.binding.mysensors" and mark it
Unfortunately I cannot find this in the list. I already added your fork as upstream master and pulled it. Anything else to change in there?
edit: solved by throwing away the openhab2 dev repo and cloning @TimO 's repo richt after installing the OpenHAB IDE. Alternatively you can create a new workspace and import/clone @TimO 's repo from there.
Run a product stays empty, interesting files are in addons/binding/org.openhab.binding.mysensors/ESH-INF/thing/
-
@powermta : What is your problem?
-
@TimO Sorry it took so long to test this. I've been flat on my back due to illness. Regardless, I tested it a bunch this morning and the changes to the zwave binding totally broke zwave functionality. The USB stick initializes but then the port gets "lost" and any attempts to interact with it fail. The change does allow for the MySensors binding to run. I removed the MySensors binding and just left your modified zwave binding in the addons folder to try to isolate the issue. It would appear that the modified zwave binding is broken. I'm going to pull the latest build from cloudbees and try your latest build of the MySensors binding and see what happens.
-
For what it's worth, I'm using openhab 2 with a version from yesterday together with the latest my sensor binding I found here. Serial gateway and serial aeon stick zwave controller (latest binding from the build server). Absolutely no issues for me.
-
@kolaf I concur. I just refreshed everything to latest snapshots and holy smokes it all works.
I'm watching my zwave rules and MySensors controls all working together. At this point, I'm not sure what was broken with my install, but both bindings are now playing with each other very well without issue.
-
I can report continued success with the MySensors binding playing nice with the Z-Wave binding.
Today I'm working out some more rules and have a situation, where when a switch state is changed we send out command to another MySensor to change two childIDs on the same nodeID and another childID on a different nodeID. Two of the messages get out to gateway with the third not going out. Here's the debug:2015-11-11 09:49:00 [DEBUG] [.b.m.p.s.MySensorsSerialWriter:40 ] - Sending to MySensors: 10;1;1;0;2;1 2015-11-11 09:49:00 [DEBUG] [.b.m.p.s.MySensorsSerialWriter:40 ] - Sending to MySensors: 9;2;1;0;2;1 2015-11-11 09:49:00 [DEBUG] [.b.m.p.s.MySensorsSerialWriter:40 ] - Sending to MySensors: 9;4;1;0;2;1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;send: 0-0-10-10 s=1,c=1,t=2,pt=0,l=1,sg=0,st=ok:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;read: 10-10-0 s=1,c=1,t=2,pt=2,l=2,sg=0:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;send: 0-0-10-10 s=1,c=1,t=2,pt=2,l=2,sg=0,st=ok:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 10;1;1;0;2;1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;send: 0-0-9-9 s=2,c=1,t=2,pt=0,l=1,sg=0,st=ok:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;read: 9-9-0 s=2,c=1,t=2,pt=2,l=2,sg=0:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 0;0;3;0;9;send: 0-0-9-9 s=2,c=1,t=2,pt=2,l=2,sg=0,st=ok:1 2015-11-11 09:49:00 [DEBUG] [.p.s.MySensorsSerialConnection:83 ] - 9;2;1;0;2;1It appears that all three messages are queued, but only the first two are actually sent. I switched the order around in the rule to send the messages in a different order and only the first two make it out to the nodes. Do I need to delay some after each command? Anyone else able to reproduce this? Thanks.
the driving rule looks like this:
rule "g01_Stair" when Item home_group_5a59cc99 changed then if (mysensors_light_508ef404_Light_10_1_status.state == ON) { // sendCommand(mysensors_light_508ef404_Light_9_2_status, ON) sendCommand(mysensors_light_508ef404_Light_9_4_status, ON) } else if (mysensors_light_508ef404_Light_10_1_status.state == OFF) { // sendCommand(mysensors_light_508ef404_Light_9_2_status, OFF) sendCommand(mysensors_light_508ef404_Light_9_4_status, OFF) } end
-
Hello Timo,
Great Work !!
Could You suggest a good Tutorial for understanding how to develope Bindings for HopenHab2?
Anyway I will study your code tooRegards
Mirko Ugolini
-
I've been testing this on my side and I have to say that is excellent.
Very well integrated with the 'Things' discovery model for OH2, etc.
The only thing that is really stopping me to move forward is OH itself. I have several (and somehow disapointing) experiences that makes me feel that is still very beta. Not sure if anyone have any update on when the RTM is expected???
Great work @TimO ! ! !
-
@mirko-ugolini The documentation on how to develop bindings for OH2 is rather thin.
Starting point is here: https://github.com/openhab/openhab2/blob/master/docs/sources/development/ide.mdFrom that point I've looked into the existing bindings and into the eclipse smarthome documentation, that does not work all the time, but the concepts match.
If you would like to contribute to the MySensors binding I will gladly help you to find the entrance.
@BenCranston I will have a look at it. Thanks for testing! The queue currently is rather basic (but should work). Maybe the data is written too fast to the serial output. I have a similar problem with OH 1.X and my rules, where I need to define a delay between commands.
Something I plan to do, is adding the ACK functionality to the binding, so if no ACK is received the command is repeated for 5 times or so.
-
@Dave-Dan said:
The only thing that is really stopping me to move forward is OH itself. I have several (and somehow disapointing) experiences that makes me feel that is still very beta. Not sure if anyone have any update on when the RTM is expected???
Yeah, I see your point. As far as I know there currently is no real roadmap for OH2, which is rather annoying. On the other side there is a really healthy discussion running on how to maintain the code. There are so many developers with bindings, bugfixes and pull requests that want to contribute, that the OH organisation has to change its structure.
At the moment the number of open pull requests for OH and OH2 is huge, so I hesitate to give the MySensors binding a shot.
-
@TimO said:
Something I plan to do, is adding the ACK functionality to the binding, so if no ACK is received the command is repeated for 5 times or so.
+1 for the ack functionality. In my opinion this is a Transport-Layer functionality and should be built into the gateway (Arduino or whatever) itself. But the main developer doesn't like the idea because he is fearful that the serial buffer (or even an arduino queue system) will be unable queue enough messages while resends happen.
On the other hand: we have plenty of RAM on our openhab hosts, so your idea seems like it will solve the problem completely, because we could even react on continous fails with putting the device offline (or whatever the openhab2 terms are for this)
-
@BenCranston : I'm pretty sure now, OH2 is sending the data too fast, because if I use terminal emulation instead of hardware all three commands are transmitted.
Just curious: are you using an ethernet or serial gateway?
-
I've added an option to influence the delay between messages send to gateway.
Possible values are 1 to 1000 milliseconds.
-
@TimO Would it be too much trouble for you to implement support for S_MULTIMETER? It seems that this is required for me to get the voltage reading from my battery driven sensors. Alternatively, is there anything you can do with the battery percentage that is sent using sendBatteryPercent? I don't know if OH2 has any notion of the sensors battery level?
I notice you have support for the type S_VOLTAGE, but I cannot find that this is present in the master branch of MySensors?
-
Also, from where can we download the latest versions of your binding?
-
And finally, GREAT WORK
-
@kolaf Thank you!
I update the download in the first post here, whenever I upload a new version.
Newest update 1 minute ago: Implementation of S_MULTIMETER!
Please let me know if this works for you.
I'm planning to add a battery channel for every sensor. So if a sensor is added via UI, you are able to select/deselect a channel you don't need it. In *.items you are free to define the channel too.
-
Thanks, that was quick. However, something is not right:
2015-11-23 17:47:17 [DEBUG] [i.DiscoveryServiceRegistryImpl:333 ] - Triggering scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:multimeter, mysensors:power, mysensors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, mysensors:light-level]' on 'MySensorsDiscoveryService'... 2015-11-23 17:47:17 [ERROR] [i.DiscoveryServiceRegistryImpl:339 ] - Cannot trigger scan for thing types '[mysensors:humidity, mysensors:temperature, mysensors:light, mysensors:multimeter, mysensors:power, mysensors:baro, mysensors:door, mysensors:motion, mysensors:smoke, mysensors:dimmer, mysensors:cover, mysensors:wind, mysensors:rain, mysensors:uv, mysensors:weight, mysensors:distance, mysensors:light-level]' on 'MySensorsDiscoveryService'!java.lang.NullPointerException: null at org.openhab.binding.mysensors.service.DiscoveryThread.stop(DiscoveryThread.java:23) at org.openhab.binding.mysensors.discovery.MySensorsDiscoveryService.stopScan(MySensorsDiscoveryService.java:63) at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:173) at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:336) at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:321) at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:172) at org.eclipse.smarthome.io.rest.core.discovery.DiscoveryResource.scan(DiscoveryResource.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606)
-
@kolaf: Interesting. I'm not able to reproduce the error. Did you clean the userdata directory? OH2 gets stuck, when the xml-Definition changes, because it uses some sort of cache.
Because it is somewhat annoying to start from the scratch after deleting userdata, I define fixed things (like the gateway) in the *.things file.
https://github.com/wishmoooop/openhab2/tree/master/addons/binding/org.openhab.binding.mysensors
-
Thanks, it seems that that was the problem.
-
Hi everyone. Just to let you know OpenHAB 2.0.0 first BETA release is available. Unfortunatelly Tim0's binding is throwing some errors while OpenHAB tryes to install it.
2016-01-13 13:46:25.314 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/home/pi/OpenHAB2/Downloads/OpenHAB-Beta/addons/org.openhab.binding.mysensors-2.0.0-SNAPSHOT.jar org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.mysensors [166] Unresolved requirement: Import-Package: gnu.io at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1245)[8:org.apache.felix.fileinstall:3.5.0] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1217)[8:org.apache.felix.fileinstall:3.5.0] at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:509)[8:org.apache.felix.fileinstall:3.5.0] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:358)[8:org.apache.felix.fileinstall:3.5.0] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:310)[8:org.apache.felix.fileinstall:3.5.0]Let me know Tim0 if I can help you fix this.
Thanks, regards.
Gonzalo.
-
kewl, thank 4 digging this up. I'm just evaluating openHab2
-
Hi Timo,
Regarding the errors in OH2beta, see this post for a possible solution.
Some other questions:
Is it possible to access sensors with different "V_types" for example V_VAR1 to a temperature sensor? I would like to send out numbers to my sensor nodes from rules.I was not able to get the battery level to work.
my item looks like this:Number SHBat "Storehouse Node Battery Level [%f %%]" (nSH,gBAT) { channel="mysensors:temperature:gateway:SHtemp_in:battery" }What is wrong?
Thank you for a great work!
/Tomas
-
Hi Tomas!
Thanks for the hint, I will take a closer look!
@ofverstedt said:
I would like to send out numbers to my sensor nodes from rules.
This is currently not possible, but it will be. It is on my ToDo list.
The current solution with the serial binding in OH 1.X is complicated, but leaves a lot of freedom for the user and I would like to preserve as much freedom as possible.I've implemented some new features a while ago, like resending of messages if no ACK is received. But the Repo is out of date. I will fix that.
-
Hi Tim0.
Really nice work with this binding. Huge step forward into a official MySensors OpenHAB binding.It would be nice to have the repo updated so as to try the new features you have implemented.
Have you had time to check why we are gewtting that error at OpenHAB 2 Beta while trying to install the binding?
Let me know if there is any way in which I can help.
Thanks, regards!Gonzalo.
-
Hi @gonzalonal !
I'm working on it. Due to the changes in the OH git repository my environment is all messed up.
-
This kind of problem (as I've read online) in this release of OH seems to be not only related to this binding. One suggestion that I found is here: https://github.com/openhab/openhab-distro/issues/82 (last comment) or here: https://github.com/openhab/openhab-distro/issues/81
I've tested it without success but I don't know if I've done it right. I've also try to build myself a rfxcom binding (this one use gnu.io) and it has the same issue
hope this help
EDIT: this work for me, run on OSGI console: feature:install openhab-transport-serial and restart OH
-
@andreacioni said:
This kind of problem (as I've read online) in this release of OH seems to be not only related to this binding. One suggestion that I found is here: https://github.com/openhab/openhab-distro/issues/82 (last comment) or here: https://github.com/openhab/openhab-distro/issues/81
I've tested it without success but I don't know if I've done it right. I've also try to build myself a rfxcom binding (this one use gnu.io) and it has the same issue
hope this help
EDIT: this work for me, run on OSGI console: feature:install openhab-transport-serial and restart OH
Hi @andreacioni.
You saved the day. It worked for me.
Here the steps I did to make it work.1- Download latest snapshot from https://openhab.ci.cloudbees.com/job/openHAB-Distribution/ (Download offline version)
2- Unzip the file.
3- Run start_debug.sh
4- In console write "feature:install openhab-runtime-compat1x"
5- Ctrl-D to exit/shutdown OpenHAB
6- Once exited, copy MySensors binding to addons folder.
7- Start againg OpenHAB-
8- Thats it. It should workRemember to copy your serial thing to things folder.
Regards!
Gonzalo
-
@andreacioni: Absolultly amazing! Thanks!
I don't understand why this helps though because the changes in the code I have to do have nothing to do with OH1 (compability).
I hope to provide an adjusted version today or tomorrow along with a clean and working repository.
Thanks for your patience!
-
@TimO I'think the OH1 compatibility is not the problem. It seems that OH2 beta1 have not installed transport feature and so it has no definition for the gno.io pakage, so I'think there's nothing to do on your code
PS tell me when the new repo is OK that I download it and try to add the baudrate config
Thanks!!
-
So, I would like to show you my current status. I've tested it against my mini MySensors environment and it looks good so far. Feel free to test.
-
Download latest snapshot from cloudbees: https://openhab.ci.cloudbees.com/job/openHAB-Distribution/lastSuccessfulBuild/artifact/distributions/openhab-offline/target/openhab-offline-2.0.0-SNAPSHOT.zip
-
Unzip file (into a directory like oh2).
-
Download the current binding from Binding and place it in the addons directory under oh2.
-
Configure addons, things, items and sitemap. Example?! addons.cfg, demo.things , demo.items, demo.sitemap
-
Start "start_debug.sh", "start_debug.bat" ...
-
In the karaf console enter: "feature:install openhab-transport-serial".
-
MySensors Plugin "should" start.
8: "log:set debug" + "log:tail" to see debug output.
Github and documentation will follow, please refer to the "old" Readme and the examples.
-
-
@TimO Hi Tim, for debugging outupt of the binding I need to write:
log:set DEBUG org.openhab.binding.mysensors, without this I cannot see anything about binding logs
-
@andreacioni Hi andreacioni. Same issue with debug mode with me. Thanks for the tip!
@TimO: V_STOP for Rollershutter sensors, is a MySensors binding limitation, or it is not implemented in OH2 yet?
Another thing I've noticed is that every item added, despite being a regular switch or a rollershutter, is is being added as:
Battery Level
mysensors:cover:gateway:Cover_1_0:battery
MySensors Battery ChannelIs this the intended behavior for every node of my sensor, despite having or not a battery?
Regards.
Gonzalo.
-
@gonzalonal said:
V_STOP for Rollershutter sensors, is a MySensors binding limitation, or it is not implemented in OH2 yet?
It is a limitation of OH2 and I don't understand the limitation. It is very confusing, because with the "RollerShutter" widget in OH2 I get three buttons: UP, DOWN and STOP. UP and down calls the handler in which I generate the MySensors message. STOP don't call the handler and therefore I can't do anything. I need to dig deeper.
Battery Level
mysensors:cover:gateway:Cover_1_0:battery
MySensors Battery ChannelIs this the intended behavior for every node of my sensor, despite having or not a battery?
This is intended behavior. The battery status is send via an internal message and there is no presentation if a sensor has a battery or not.
I've therefore added the battery channel to every item. In Paper UI you are able to simply disable the channel by clicking the blue circle next to the battery channel or in the configuration file you have to specify the channel, if you want to use it. If the battery channel is not defined for a thing it won't receive the battery status.For the future: maybe there is a way to hide the channel as long as there was no battery status received and display it only when used. But currently I don't see an easy way to implement that.
Greetings!
Tim
-
@TimO
Great TimO. Thanks for clarifying this topic.
Regards.
Gonzalo
-
@gonzalonal : I found a solution for V_STOP! It will be available soon.
But more important: @andreacioni is doing some great work improving the stability and performance of the binding!!
I just wanted to let you know, that the binding is currently under heavy development.
-
@TimO
Great news TimO. Really nice to hear that.
Regarding STOP functionality for the binding, I have read somewhere that the supported commands by OpenHAB, for RollerShutter items, are Up, Down and StopMove. Have yoy tried something like this?Regards
Gonzalo.
-
@gonzalonal said:
Regarding STOP functionality for the binding, I have read somewhere that the supported commands by OpenHAB, for RollerShutter items, are Up, Down and StopMove. Have yoy tried something like this?
Yeah, my problem till yesterday was, that I was not able to cast the given state to StopMoveType in case of Stop, while casting the state to UpDownType for Up and Down was no problem.
I changed the way how the binding handles this type of message and it works now.
-
@TimO
Can we clone the latest source code from this binding? I think that your github repository is outdated and I want to work this weekend with it, 'cause I would like to integrate the mysensors 2.0-beta "smartSleep" feature with your binding in my home sensors setup (ESP8266 Ethernet GW).Also, if there are any ISSUE y your TODO list in which I can help you, please tell me.
Regards
-
Hi Sebastián, what repository have you checked? Currently the development is not on the old https://github.com/wishmoooop/openhab2/tree/master/addons/binding/org.openhab.binding.mysensors but was moved here: https://github.com/tobof/openhab2-addons/tree/MySensors/addons/binding/org.openhab.binding.mysensors
Hope this help
-
@andreacioni said:
Hi Sebastián, what repository have you checked? Currently the development is not on the old https://github.com/wishmoooop/openhab2/tree/master/addons/binding/org.openhab.binding.mysensors but was moved here: https://github.com/tobof/openhab2-addons/tree/MySensors/addons/binding/org.openhab.binding.mysensors
Hope this help
Thanks @andreacioni
I was working on the old repo!
-
I've updated the first posting in this thread. You'll find the current repo there (also).
I've added a Wiki to the repo and made a brief description of the installation and configuration process.
https://github.com/tobof/openhab2-addons/wiki
The current binding (jar) is also in the repo now. You'll find the link in the wiki under "Installation".
Modifications in the current version:
- RollerShutter now supports STOP
- Performance of the binding improved. Big thanks to @andreacioni !!
- Stability improved. Also big thanks to @andreacioni
- Error handling on connection loss improved
- The baud rate of the serial gateway is now adjustable. (@andreacioni again!)
- some code cleanup: removed not needed debug output etc.
Please let me know if you found the time to test the binding and what the results are.
-
@TimO said:
I've updated the first posting in this thread. You'll find the current repo there (also).
I've added a Wiki to the repo and made a brief description of the installation and configuration process.
https://github.com/tobof/openhab2-addons/wiki
The current binding (jar) is also in the repo now. You'll find the link in the wiki under "Installation".
Modifications in the current version:
- RollerShutter now supports STOP
- Performance of the binding improved. Big thanks to @andreacioni !!
- Stability improved. Also big thanks to @andreacioni
- Error handling on connection loss improved
- The baud rate of the serial gateway is now adjustable. (@andreacioni again!)
- some code cleanup: removed not needed debug output etc.
Please let me know if you found the time to test the binding and what the results are.
Thank you @TimO !
This weekend I started migrating from my OH1.8 + mqtt GW setup to OH 2 beta + your binding. At the moment all is working fine, I spent some time learning about OH2 / Eclipse smartHome and watching your code, because I want to implement the smartSleep feature (https://github.com/mysensors/Arduino/pull/271) in the mysensors binding.My idea is: when the handler don't receive an ACK from a message, it store the message for a while, waiting a heartbeat from a node, and, if the binding has some message stored for this node, then send it again. I don't know if this is correct, or if you thinks there is a better solution.
Regards
-
@Sebastián-Zaffarano said:
This weekend I started migrating from my OH1.8 + mqtt GW setup to OH 2 beta + your binding. At the moment all is working fine, I spent some time learning about OH2 / Eclipse smartHome and watching your code, because I want to implement the smartSleep feature (https://github.com/mysensors/Arduino/pull/271) in the mysensors binding.
My idea is: when the handler don't receive an ACK from a message, it store the message for a while, waiting a heartbeat from a node, and, if the binding has some message stored for this node, then send it again. I don't know if this is correct, or if you thinks there is a better solution.
That sounds like a good plan. The binding already uses a queue where messages that should be send are buffered and you are able to specify how long a message is hold in the queue (when it is time to send again).
I've already implemented a mechanism to request for an ACK message. This mechanism sends a message to the node, but holds this message in the queue and increments the number of retries (currently 4 retries, with different/longer delays). If the node responds with an ACK or the number of retries exceeds 4 the message is removed from queue. So you could indicate, with a configuration setting, that the node is an smartSleep node and thus only send the message once and if no ACK is received store the message for 10 minutes (for example) in the queue.
Here is the implementation: https://github.com/tobof/openhab2-addons/blob/MySensors/addons/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/protocol/MySensorsWriter.java
BUT: The reader and the writer are working in different threads (asynchronus), so we have to sync the threads (the queue), if we receive an ACK and remove a message from the queue. I'm still struggling with that and that is the reason why the request for ACK should not be used at the moment and this will be a problem for smartSleep too.
According to the ACK feature: if the binding don't receive an ACK after 4 timeouts it will revert the status of the thing to the last value. So if you for example try to switch on your light and the message is not acknowledged, the binding will revert the switch state to off. I've removed the code for this, because of the issue above, but will add it again in the future.
-
Hello everyone
I'm testing MySensor Ethernet gateway with a relay code on it. My understanding that Gateway stores the current state of the relay (or GPIO port) in it's EPROM. Can the binding periodically check the state of the port or should I rely on OH persistence functionality? Please advise what is the right way to keep the states synced between the Gateway and OH.
Thanks
Andrew
-
Hi Andrew!
Good question. Polling is currently not supported by the binding itself, but what you could do is: send a message from the node to the gateway, when the node restarts (the moment after you read the EEPROM and set the output of the pin).
Greetings
Tim
-
@TimO , thanks for the idea.
So I can probably take some code used for reporting button presses in the examples and use it in the 'message'.Thanks again
Andrew
-
Hi Tim0.
I have read all your instructions in the GitHub Repo.
Is there any special reason why you suggest to add things in manual, text way, rather than with the PaperUI?I have done it with the PaperUI and manually restarting my nodes and everything works just fine.
Let me know what you think.
Regards
-
I wondered that but I'm quite new to OpenHab so did some looking in to how various things work..
PaperUi uses something called MapDB which is basically a non-human readable configuration file. If you add "things" via PaperUi as far as I can tell you've still got to link the thing to an item for OpenHab to work with as far as I can tell..
I opted to do everything manually like in the wiki, seems much simpler
I get the impression PaperUi is still very new and not for production yet... its not compatible with sitemaps as they are waiting to implement a version of sitemaps in PaperUI or something.. I think it all boils down to the fact they want to keep V2 100% compatible with V1 configs and bindings etc so all the new stuff in V2 isn't quite ready yet...
Anyway might have totally got the wrong impression but that's what I see as a new OpenHab user going straight to v2.
On another note the work your doing TimO is awesome!
-
I totally agree with @Qu3Uk !
Both ways work and currently I like the configuration with the .items file more.In an early version of the PaperUI it was possible to change the status of items (switch lights on and off). Maybe something like this will return or habmin2 will fill the gap.
-
I need support for HVAC device, how much work is there to be done to get that included.
I have made a thermostat controller for my Wirsbo floor project can be found under myprojects wirsbo uponor thermostat replacement
-
@Denke What is it exactly what you need? Which types?
How is the setpoint set (request/send)?Greetings
Tim
-
@TimO
Hi Tim
I use gw.present(0, S_HVAC); to present the sensor to the controllerI use the following messages to send information
MyMessage msgTemp(0,V_TEMP); //temperature of thermostat
MyMessage msgFlowState(0,V_HVAC_FLOW_STATE); //tells if the thermostat is active HeatOn or off
MyMessage msgSetpointHeat(0,V_HVAC_SETPOINT_HEAT); //used for setting wanted temperature
MyMessage msgKnobTemp(0,V_VAR1); //gives the wanted manual temperature set on the thermostat knob (used for fallback when home automation dont work
MyMessage msgRunningMode(0,V_VAR2); //running mode internal or external internal = knob value used, external set by home automation
MyMessage msgHystLow(0,V_VAR3); //used if hysteresis needs to be changed (low value)
MyMessage msgHystHigh(0,V_VAR4); //used if hysteresis needs to be changed (high value)
MyMessage msgUpdateTime(0,V_VAR5); //used to set system sampling/update timeAll of the above values are sent out from the thermostat at update sampling time interval.
V_HVAC_SETPOINT_HEAT(msgSetpointHeat), V_VAR3(msgHystLow), V_VAR4(msgHystHigh), V_VAR5(msgUpdateTime) can be set from the controller to update the thermostat parameters
-
Hi TimO.
I am trying to do a gw.request from one of my nodes that requires the value of a numeric item from OpenHAB.
Have you tested this? I am unable to make it work.
I have created a rule:
rule "Heart Rate request" when Item Heart_Rate received command then if (receivedCommand == "REQUEST") { logInfo( "Heart Rate", "Heart rate request") sendCommand(Heart_Rate, Heart_Rate.state); } endPlease, let me know if I am doing it the wrong way.
Regards.
-
I seem to be having some issues with the dimmer function and I'm not entirely sure if its OpenHab, the binding or MySensors... but I seem to be able to crash the gateway once OpenHab boots up... The node is basically running DimmerLED stretch
20:31:13.030 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 7;1;1;0;0;33.8 ... 20:31:13.596 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Light_APT_Lounge_TV' received command ON 20:31:13.598 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 8;0;1;0;2;1 20:31:13.602 [INFO ] [marthome.event.ItemStateChangedEvent] - Light_APT_Lounge_TV changed from NULL to 100 20:31:14.599 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete. 20:31:27.963 [WARN ] [g.mysensors.protocol.MySensorsReader] - Connection to Gateway lost! 20:31:27.964 [DEBUG] [g.mysensors.protocol.MySensorsReader] - Stopping Reader thread 20:31:27.965 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mysensors:bridge-eth:gateway' changed from ONLINE to OFFLINEI notice the ItemState is null and that sort of makes sense why if OpenHab has been restarted but surely if it is null it shouldn't cause the gateway to go offline? Also it doesn't reconnect which is probably more of an issue.
Bridge mysensors:bridge-eth:gateway [ ipAddress="192.168.1.150", tcpPort=5003, sendDelay=200 ] { dimmer light08 [ nodeId="8", childId="0" ] }Items
Dimmer Light_APT_Lounge_TV "TV Lights" <light> (Lights, APT_Lounge) { channel="mysensors:dimmer:gateway:light08:dimmer" }
-
I finally found some time to develop on the binding.
A new version is available with the following changes:
-
On startup the binding will request I_VERSION from gateway to ensure its proper startup. Thanks @andreacioni for the PR!!
-
HVAC (V_VAR1, V_VAR2 ...) are now available. Thanks @Denke for the PR!!
-
The request for ACK feature is now available for testing. It works for light/status for me. If a message is NOT acknowledged by a node the binding retries to send the message five times. If no ACK is received after that the binding will try to revert the item to its old state. This only works, if a state is known (not NULL, for example at startup).
Additionally I've tested the binding with multiple gateways (one EthernetGW, one SerialGW), works fine.
-
-
Hi @TimO.
I have just installed the new release and I believe I've found a little bug. I am using Serial Gateway with version 1.5.3At boot up time, I am getting the followinf error:
03:07:52.644 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not receivedI have read that this new release, request the gateway for its version so as to prove proper start up.
What I have found is that the binding might be asking for the Gateway version al little too soon.
03:07:50.895 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2; 03:07:50.912 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete. 03:07:52.644 [ERROR] [s.internal.MySensorsBridgeConnection] - Cannot start reading/writing thread, probably sync message (I_VERSION) not received 03:07:52.647 [DEBUG] [col.serial.MySensorsSerialConnection] - Shutting down serial connection! 03:07:52.659 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Stopping Writer thread 03:07:52.661 [WARN ] [g.mysensors.protocol.MySensorsWriter] - Writer thread interrupted 03:07:52.666 [DEBUG] [g.mysensors.protocol.MySensorsReader] - Stopping Reader threadI have tested this manually and found that the gateway ONLY answers its version after its startup is finished and the message "0;0;3;0;14;Gateway startup complete." is sent.
When the binding starts, It makes (somehow) the gateway to reboot. So, the gateway runs its setup() method and when it's done, it send the message "0;0;3;0;14;Gateway startup complete"
Let me know if you can reproduce this error. Maybe it's just some problem with my setup, but with the previus version I was having no issues.
Regards!
-
@gonzalonal I've implemented the check on startup. On serial gateway with the last version I'm not having any issue, so I would like to know: what hardware are you using? I think that probably is only a timing issue because, for exaple, Arduino UNO reset itself on opening connection and the message for request I_VERSION is sent immediately after connection is opened. I'll suggest you to try adding something like this:
Thread.sleep(3000)After line 49 on MySensorsSerialConnection.java. Should become:
serialConnection = new NRSerialPort(serialPort, baudRate); if (serialConnection.connect()) { logger.debug("Successfully connected to serial port."); Thread.sleep(3000); mysConReader = new MySensorsSerialReader(serialConnection.getInputStream(), this); mysConWriter = new MySensorsSerialWriter(serialConnection.getOutputStream(), this, sendDelay); connected = startReaderWriterThread(mysConReader, mysConWriter); } else { logger.error("Can't connect to serial port. Wrong port?"); }I can't do this test because I do not have an appropriate hardware, can you try the suggested code modification?
Thanks!
UPDATE: I've upload a temp build here: https://drive.google.com/file/d/0B11IarucpGdUdFJ2ZjVtZENsb2c/view?usp=sharing if you can't do the modification you can use this. Let me know!
-
Hi @andreacioni. Thanks for your answer.
I have tested your custom build and it's working flawlessly.09:10:36.913 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;14;Gateway startup complete. 09:10:37.161 [DEBUG] [g.mysensors.protocol.MySensorsWriter] - Sending to MySensors: 0;0;3;0;2; 09:10:37.172 [DEBUG] [g.mysensors.protocol.MySensorsReader] - 0;0;3;0;2;1.5.3 09:10:37.177 [DEBUG] [s.internal.MySensorsBridgeConnection] - Good,Gateway is up and running! (Ver:1.5.3)Let me tell you about my hardware configuration. I am running OH2 Beta2 in a Raspberry Pi 2 Model B with an Arduino Nano V3 working as Serial Gateway directly connected to one of Rpi USB ports.
Please, let me know if you need me to some tests or maybe is just my config.
Thanks, regards.
-
@gonzalonal I've done all of my test on a custom ATMEGA328p shield for BeagleBone Black, running OH2 (beta) so the environment is the same but I've not the reset circuit that gives the issue above. So now I'll push this little fix on the github repo, I think there's nothing to to in this sense. Thank for your time
!If you find some other strange behaviour also remember that github repo has it's own issue tracker available here: https://github.com/tobof/openhab2-addons/issues, it works very well and is the best place to keep track of every software-releated bug
Greetings!
-
There is a new build of the jar available!
Changes:
- Added delay before checking the SerialGW (@andreacioni )
- Requests are answered by the binding (The binding returns "0" if no value was set before)
-
Are any of you having trouble with this binding together with other bindings that use serial ports? It looks as if the different bindings try to use the same serial port lock, so I get a conflict where things fail til initialize. Think it had something to do with the serial port library...
-
@kolaf Is it zwave again? Last time I tried to fix the conflict I needed to change the zwave binding.
-
It is both zwave and rfxcom. I played about it in the oh2 community some time ago, let me see if I can find a link.
-
-
Hello @TimO .
Just tested the last build of the binding. Works great.
I see you manage to answer the nodes requests without having to trigger a rule to respond.I though that wasn't possible due to the limitation of the API. Did they manage to solve this from the OH side?
Does the binding itself keeps track of the items values, or does it querys OH (or its persistence service) for getting the right value?
Thanks!
Gonzalo
-
Hi @gonzalonal !
I'm glad it works, thanks for testing!
Sadly the limitation of the API is still there, but for the implementation of the requestAck feature I needed to implement a memory and now reused this memory to answer requests.There is a really big BUT coming with this implementation: we currently can't use persistence out of the box. For this a rule is needed. After startup of OH we need to use "sendCommand(ITEMNAME, VALUE)", where VALUE Is the value stored in persistance. With that the memory of the binding is filled initially.
Hopefully I will find an easier way in the future .
-
I get what you mean @TimO .
Unfortunatelly, using the rule method you suggest would create a lot of traffic (depending on how many sensors you have) at boot up time. Maybe there are some sensors that wouldn't behave the intended way if receiving the "last value" repeteadly.
An example. Lets supose I have an automatic gate, that everytime it receives a command, wether its a "1" or "0" it toggles its moving direction. Like the most common automatic gates remotes.
Gate is closed.
Press button > Gate opens
Press button > (if gate moving) Gate stops
Press button > (if gate open) Gate closesNow, suppose last command send to the gate made it close. Suddenly, OH restarts itself because of power failure or whatever. It runs the rule to load the memory of the binding, while at the same time it sends to the sensors the last status taken from the persistance service. This would make the gate to open without your notice.
This may create dangerous escenarios.
I hope you can understand what I mean.Maybe it would be a better idea to handle requests with rules in the way I suggested in the github issue, that is the same way as the OH-1 mysensors serial binding works.
Let me know if I can help in any way.
Regards.Gonzalo.
-
@gonzalonal Good point!
If a request (or a message in general) is received there is no "commandReceived" in OH, so you can't trigger a rule based on a message received. So doing it with a rule is not possible.
A workaround would be to use "postUpdate()" to update the value after restart. This isn't implemented yet, but is no big deal. This would be a workaround for the workaround, because we still need the rule.
In the OH1 binding the request is answered with the state of the item, as I would like to to do too.
Line 277: https://github.com/bloft/openhab/blob/master/bundles/binding/org.openhab.binding.mysensors/src/main/java/org/openhab/binding/mysensors/internal/MySensorsBinding.java
-
Hi @TimO . Good we got in the same page.
I think this topic needs some more thinking.
I was reading OH wiki and found this about receivedCommand.
Implicit Variables inside the Execution Block Besides the implicitly available variables for items and commands/states (see the script documentation), rules can have additional pre-defined variables, depending on their triggers: * Every rule that has at least one command event trigger, will have the variable receivedCommand available, which can be used inside the execution block. * Every rule that has at least one status change event trigger, will have the variable previousState available, which can be used inside the execution block.https://github.com/openhab/openhab/wiki/Rules
Maybe this is not available anymore, or at least on OH2.
For now, I think it would be a better approach to use postUpdate at systemStart to populate the binding memory. With this, we'll avoid sending commands to the nodes.
Regards!
-
Hi again @TimO .
Just an idea.
What do you think about solving this problematic in this way:
We create a group whose members are all those items that later will populate the binding's memory. I have a group named mysqlpersisted where I put all the items whose data will be stored in my SQL DB. So I could use that group. For this example, let's call it "MemoryGroup"
Then, we can create the following rule:
rule "Populate MySensors binding memory" when System started then (maybe add a delay to allow persistance services to load) MemoryGroup?.members.forEach[i | postUpdate(i.name, i.previousState(true)) ]Using this method, memory would get populated everytime OH boots up, with data belonging to the persistance service that we use. And we use postUpdate, so no command is sent to the nodes.
With this I think we solve both problems as data in the binding will be concurrent with the persistance service data.
Let me know what you think about this.
Regards!
-
Hi @gonzalonal !
I was thinking in the same direction and I have played a litte bit with different rules. I had no success in finding a rule that worked. Additionally I don't like the workaround.
A good solution would be, to trigger a rule, if a request is received, but there too I had no success till now.
I'm still struggling with it ...
-
@TimO Do you think it would be hard to add MQTT support to the binding? I had a brief look to your code and it looks like the protocols are nicely isolated.
-
I'm currently trying to migrate my production environment from OH1 to OH2. I'm now using two serial gateways.
@kolaf : The problem you described occured to me too. In my case I use two serial gateways. I've added a little method that ensures that a connection to more than two serial ports via nrjavaserial is possible. It works within the OH2 binding. Could you test if it works with the RFXCOM binding you are using? A new jar is available on github. OH2 is currently using an old version of nrserialjava that has a bug. I don't know how to switch the version yet.
@tomkxy : I will integrate MQTT in my OH2 Installation soon and will come back to your request after that.
-
The binding doesn't seem to handle the "requestTime" function yet. Time-aware sensors would be able to handle temporary OpenHAB outages by executing some scheduled actions autonomously, which I could use in the window cover controllers I'm developing.
