Thanks for creating this binding. I would like to use it for in my setup. I’m trying OH2, and your binding is for OH1. Are you planning to migrate the binding to OH2 binding?
I’m learning how to create new binding in OH2 (I’m a newbie). And I’m thinking of how to create a binding for MyQ in OH2. But there’s a problem in discover the devices. I know I can use Discovery Service. And it seems natural that the devices associate with my MyQ account can be found as things via it. However, I’m not sure how to create configurations (e.g. username/password) for the Discovery Service. The documented configuration in Eclipse Smart Home seems to be for things only.
I started a OH2 binding for MyQ in my personal github but I haven’t worked on it much yet. The 1.x binding is compatible with OH2 and worked the last time I tried it.
I follow the page https://github.com/openhab/openhab/wiki/Chamberlain-MyQ-Binding to setup items and sitemap in OH2. I can tell from the log that it’s updating the status successfully. But from the UI, I don’t see a thing for my device. Is there a way to show that in OH2?
There are somehow illegal characters in your openhab.cfg file. Open it with a text filed editor and remove the garbage characters, save, and restart openHAB.
I have 9 MyQ Items
1 Universal MyQ Gateway + GDO
4 Lamp modules
5 Switches
I’m using the 1.9.0 Snapshot Binding from the 1.9.0 Binding Package.
2016-12-29 20:45:12.803 [ERROR] [inding.myq.internal.MyqBinding] - Could not connect to MyQ service java.io.IOException: Null response from MyQ server at org.openhab.binding.myq.internal.MyqData.request(MyqData.java:208) ~[bundlefile:na] at org.openhab.binding.myq.internal.MyqData.getMyqData(MyqData.java:120) ~[bundlefile:na] at org.openhab.binding.myq.internal.MyqBinding.poll(MyqBinding.java:204) [bundlefile:na] at org.openhab.binding.myq.internal.MyqBinding.access$0(MyqBinding.java:196) [bundlefile:na] at org.openhab.binding.myq.internal.MyqBinding$1.run(MyqBinding.java:401) [bundlefile:na] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_65] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_65] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [na:1.8.0_65] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [na:1.8.0_65] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_65] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_65] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_65]
I get this error pretty often. I find that if I disable most of the attributes it happens less. Is this something that can be fixed by adjusting the timeout or the refresh interval?
Any one have any clue why I periodically get Cannot connect to MyQ Service?
Am I hitting a limit on the API.
Is anyone else seeing this type of behaviour?
When I take a look at the code of the binding it looks like when the binding gets a command it enters in to a rapid poll rate. Which makes sense for a garage door openers (GDO) to get the open/close and intermediate states.
I think with multiple MyQ none-(GDO) items I’m maybe overwhelming the API with the rapid refresh and this also introduces some oddities in to the Bus.
I notice that when I’m using a switch for a scene or a rule that links many MyQ items that when for example Item myQ_light1 changes to ON sendcommand MyQ_light2 ON and another condition for an off condition. Light2 during the rapid refresh period will do on off on off cycle because the MyQ API reports the changing status of Light1 about 3 times a second. This also results in more commands being sent for light2 than desired and floods the bus. So far I’ve been using thread::sleep (5000) to ensure that I don’t send too many updates/commands in to the bus.
Does anyone notice this? Would disabling rapid refresh for non-GDO be a good change for the lamp portion of the plugin and let the bus post the updates?
Or am I completely off base?
You’re fast.
I had built my own Jar to test my theory.
I was going to report back after I had confirmed it.
I had set the code to false for lamp modules and fixed some typos in the
MyQResponseCode.java
``` UNKNOWN(-1, “Unknow resonse”);``
The jar with the disabled rapid poll for lamp modules fixes the first error I saw and reported.
The response of lamp modules especially in groups is slightly faster and more robust as now it’s only reporting status on change and @ 1 per minute as per the configured refresh interval.
From my short test I think having rapid poll false for lamp modules is the way to go.
I have 11 MyQ items in total and with the official 1.9.0 SNAPSHOT binding anytime I was sending commands to myq group triggered by a myq status change would result in some disney’s haunted mansion craziness and slow response on my Rpi2 due to the bus getting flooded.
@tebore
I removed quick polling for the lamp modules but I didn’t want to wait a full minute for the status update. So I added a get status call 2 seconds after the set state request is sent. I am going to make it a configurable parameter but I wanted to get a fix for you to try. I hope to work on it some more tonight and add the source code to my github if you want to test it.
I’m curious if that 2 second poll after the set state is required.
I’m just thinking out loud.
Commands sent via HAB update the states, unless for some reason the API is slow and the tail end 60 second refresh of the states overrides the sent command with the actual state of the item before the desired state is set at the switch (I’ve had this happen once or twice but waiting a bit eventually everything syncs up).
I also remember that if the switch changes physically (physically flipping of the switch) it also updates the API and that will update the HAB.
I took a look at the code, there’s no way to make MyQ response times better correct? The delay is in the cloud nature of the product? There’s a ~ 1 second delay on top of the Native MyQ App.
Just a suggestion: The Ecobee and Garadget bindings have a “quick poll” configuration setting that tells the binding to poll state sooner after a command is sent to the remote system, so the user gets feedback sooner than a normal poll cycle. It might be one way to look at how to poll state for MyQ.
I’m new to Openhab and setup, and I’ve been trying to read and figure this out myself, but I’m not having any success.
I’ve configured MyQ with one garage door successfully and would like to add a second garage door, but I’m not sure where to start. I’ve made the following changes to my items and sitemap files but it still only recognizes one garage.
Group gMyOpenHAB
/MYQ Garage/
Group Garages
Switch GarageDoorSwitch “Garage Door Open” (Garages, gMyOpenHAB) { myq=“1” }
String GarageDoorString “Garage Door [%s]” (Garages, gMyOpenHAB) { myq=“1” }
Contact GarageDoorContact “Garage Door [%s]” (Garages, gMyOpenHAB) { myq=“1” }
Rollershutter GarageDoorShutter “Garage Door Open” (Garages, gMyOpenHAB) { myq=“1” }
String GarageDoorDesc “Garage Door Desc [%s]” (Garages) { myq=“1#desc” }
String GarageDoorOnline “Garage Door Online [%s]” (Garages) { myq=“1#online” }
String GarageDoorDeviceId “Garage Door Device Id [%s]” (Garages) { myq=“1#MyQDeviceId” }
String GarageDoorDeviceType “Garage Door DeviceType [%s]” (Garages) { myq=“1#MyQDeviceTypeName” }
String GarageDoorSerialNumber “Garage Door SerialNumber [%s]” (Garages) { myq=“1#SerialNumber” }
Switch GarageDoorSwitch2 “Garage Door Open” (Garages, gMyOpenHAB) { myq=“2” }
String GarageDoorString2 “Garage Door [%s]” (Garages, gMyOpenHAB) { myq=“2” }
Contact GarageDoorContact2 “Garage Door [%s]” (Garages, gMyOpenHAB) { myq=“2” }
Rollershutter GarageDoorShutter2 “Garage Door Open” (Garages, gMyOpenHAB) { myq=“2” }
String GarageDoorDesc2 “Garage Door Desc [%s]” (Garages) { myq=“2#desc” }
String GarageDoorOnline2 “Garage Door Online [%s]” (Garages) { myq=“2#online” }
String GarageDoorDeviceId2 “Garage Door Device Id [%s]” (Garages) { myq=“2#MyQDeviceId” }
String GarageDoorDeviceType2 “Garage Door DeviceType [%s]” (Garages) { myq=“2#MyQDeviceTypeName” }
String GarageDoorSerialNumber2 “Garage Door SerialNumber [%s]” (Garages) { myq=“2#SerialNumber” }
