Imperihome - missing devices
-
While i wait for a replacement app for my local UI devices, i want to use imperihome as long as I can.. But i'm missing a lot of devices!
All Z-Way bridge devices, all security/smoke and motion sensors (local RFXtrx child devices)..
Found the "include vera bridge" in imperihome.lua, what else could cause this?
-
You probably have better things to do, @akbooer , but mabye you could point me in the right direction? How to debug this?
Imperihome (Pro without monthly subscription) still works flawlessly on my units, so it would be great to be able to use it..
I tried linking in z-way directly, but had some errors with that too..What tools do you plugin developers use when working with Lua/Luup?
-
Sorry, not an Imperihome user here, so haven’t really a clue. I might guess, though, that it doesn’t like the high device numbers that bridged devices are assigned?
For all my Lua development, I use ZeroBrane Studio. You will not find a better IDE. I run the whole of openLuup within it to debug development code.
-
Cool, I'll have a look at that.
I see that i have the wrong "booer"! This was written by renebooer, and not akbooer! sorry about that, sent a message to rene now..
-
@perh said in Imperihome - missing devices:
I see that i have the wrong "booer"!
Yes... what are the chances of that ?!
-
@perh said in Imperihome - missing devices:
While i wait for a replacement app for my local UI devices, i want to use imperihome as long as I can.. But i'm missing a lot of devices!
All Z-Way bridge devices, all security/smoke and motion sensors (local RFXtrx child devices)..
Found the "include vera bridge" in imperihome.lua, what else could cause this?
I had the same issue. Check that the attribute "disabled" is not set to '1' for the missing devices. See this thread
-
I saw that thread, but mine aren't disabled..
-
Hi,
From what I could see is that the z-way devices are not having a category or subcategory number set. These are used to map to an Imperihome device type and thus failing and ignored. Are these numbers being left out intentionally, or is this some bug? (@akbooer ?)
Cheers -
Just another one of those things that have not been done for the ZWay plugin. AFAIK, you can set these manually?
It's a side-product of not having a device database, although it should be possible to start with a reasonable set. It's all back to Vera's failings, again, since what is the point of having a device type if you also need a category/subcategory (OK, it's for the UI, but you get the point.)
-
I already suggested to provide a minimal mapping, by default. It will not hurt and it's pretty trivial. A good part of the categories could be easily mapped to device types.
-
I'll just set them manually, no hurry for me.
If its a straight forward job, i could give it a stab with some initial guidance?
-
I can have a look if all mappings can be on the device type that would remove the need on the category value, but not sure if that applies to all or not.
Cheers -
That would be great, @mrFarmer. Again, i think i can help with basic code generation if its a set format you can show me.
One of the devices i've manually changed categories on doen't work properly:
from Imperihome:
2020-11-20 17:18:44.869 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=879952081&Timeout=60&MinimumDelay=1500&_=1605887227784 HTTP/1.1 tcp{client}: 0x55a32131d328 2020-11-20 17:18:44.983 openLuup.server:: request completed (55233 bytes, 4 chunks, 114 ms) tcp{client}: 0x55a32131d328 2020-11-20 17:18:45.108 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=879952111&Timeout=60&MinimumDelay=1500&_=1605887227785 HTTP/1.1 tcp{client}: 0x55a32131d328 2020-11-20 17:18:45.602 openLuup.server:: GET /cgi/imperihome.lua?query=/devices/20170/action/setStatus/1 HTTP/1.1 tcp{client}: 0x55a3228a48d8 2020-11-20 17:18:45.603 luup.call_action:: 20170.urn:upnp-org:serviceId:SwitchPower1.SetTarget 2020-11-20 17:18:45.603 luup.call_action:: action will be handled by parent: 198 2020-11-20 17:18:45.603 luup.variable_set:: 20170.urn:upnp-org:serviceId:SwitchPower1.Target was: 0 now: 0 #hooks:0 2020-11-20 17:18:45.629 openLuup.server:: request completed (37 bytes, 0 chunks, 26 ms) tcp{client}: 0x55a3228a48d8 2020-11-20 17:18:45.735 openLuup.server:: request completed (12708 bytes, 1 chunks, 626 ms) tcp{client}: 0x55a32131d328 2020-11-20 17:18:45.771 openLuup.server:: GET /cgi/imperihome.lua?query=/devices HTTP/1.1 tcp{client}: 0x55a3228a48d8 2020-11-20 17:18:45.779 openLuup.server:: request completed (16819 bytes, 0 chunks, 8 ms) tcp{client}: 0x55a3228a48d8From AltUI:
2020-11-20 17:18:53.135 openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=20170&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1 HTTP/1.1 tcp{client}: 0x55a321d47e58 2020-11-20 17:18:53.136 luup.call_action:: 20170.urn:upnp-org:serviceId:SwitchPower1.SetTarget 2020-11-20 17:18:53.136 luup.call_action:: action will be handled by parent: 198 2020-11-20 17:18:53.137 luup.variable_set:: 20170.urn:upnp-org:serviceId:SwitchPower1.Target was: 0 now: 1 #hooks:0 2020-11-20 17:18:53.172 openLuup.server:: request completed (35 bytes, 1 chunks, 36 ms) tcp{client}: 0x55a321d47e58 2020-11-20 17:18:53.596 openLuup.server:: request completed (12708 bytes, 1 chunks, 3688 ms) tcp{client}: 0x55a32131d328Any ideas why Imperihome doesnt work? Other devices (local and verabridge) works fine.
-
Ok, so i've looked into what happens. This is what is fed into the call_action at line 684 in luup.lua.
Format:
e,m,j,a = dev: call_action (service, action, arguments, devNo)Switching a local device from AltUI (Works):
e,m,j,a = dev: call_action ("urn:micasaverde-com:serviceId:SecuritySensor1", "SetArmed",{DeviceNum = "65", action = "SetArmed", newArmedValue = "1", serviceId = "urn:micasaverde-com:serviceId:SecuritySensor1"}, 65)Switching a local device from Imperihome device (Works):
e,m,j,a = dev: call_action ("urn:micasaverde-com:serviceId:SecuritySensor1", "SetEnabled", {newArmedValue = "0"}, 65)Switching a VeraBridge device from AltUI (Works):
e,m,j,a = dev: call_action ("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {DeviceNum = "10308", action = "SetTarget", newTargetValue = "1", serviceId = "urn:upnp-org:serviceId:SwitchPower1"}, 10308)Switching a VeraBridge device from Imperihome device (Fails):
e,m,j,a = dev: call_action ("urn:upnp-org:serviceId:SwitchPower1", "SetTarget", {newTarget = "0"}, 10308)No error messages in the luup log, just no end result.. Any ideas?
-
So I notice that those requests use different parameter names: newTarget / newTargetValue.
This would certainly explain it.
The question is, where does this difference occur?
-
That was it.
/cgi/Imperihome.lua: Changed "newTarget" to "newTargetValue" at line 385, 672 and 675. (i would upload the updated lua file, but im missing priveleges)
This was not an issue before, has there been changes on this in openluup?
@mrFarmer - FYI
-
Careful here.
Vera/MiOS has an appallingly bad trait of using different names for the same thing in different places. It's worthwhile checking the documentation between the action Luup call and the HTTP request. I'm not aware of a significant change in openLuup in this area, but have vivid recollections of the pains that this put me through in the relatively early stages of development.
I might be wrong, it could be a latent error lain undiscovered for years, but you're perhaps in a better position than I to investigate this (I don't use, or even have, Imperihome.)
-
@perh said in Imperihome - missing devices:
That was it.
/cgi/Imperihome.lua: Changed "newTarget" to "newTargetValue" at line 385, 672 and 675. (i would upload the updated lua file, but im missing priveleges)
This was not an issue before, has there been changes on this in openluup?
@mrFarmer - FYI
I modified the right lines, it really works now!
At the same time, I can see the icons on the imperihome flashing as if they are constantly reloading ... -
@PerH, haven't you experienced this?
10/29
