It is solve with 
change python in python3
Switch IR “IR” (ZG_salone, AV) {exec=">[ON:python3 /usr/share/openhab/addons/orvibo.py -i 192.168.1.3 -e /usr/share/openhab/addons/ir/hifipower.ir]"}
Hi
Thank you @Pavel_Cherezov for your python module. I started using your module to control my AC with the AllOne IR blaster. I recently bought a S20 smart socket for use with a lamp eventually. I got it to work. All of my Orvibo integration is through the exec command running separate python3 scripts. I am absolutely loving openHAB and now have a mix of INSTEON and Orvibo products working.
The problem I am having is the delay. The WiWo app controls the AllOne and the S20 socket pretty much instantly while running the python script seems to have a little delay.
From what I understand, you need to subscribe to the device before you can control it and perhaps this is introducing a delay in the python script.
Is there something I need to keep running in the background to keep subscribed? The delay is alright but since the app is so zippy I was wondering if there was a way to make openHAB and the orvibo python module behave just as quick.
Thanks
Thank you @robinson for your feedback!
AFAIU you have already digged my module, and you absolutely right - it connects and then subscribes to the divice before each request. It actually was done mainly by couple reasons:
- Having active connection and/or active subscription to the device breaks discovering devices.
- Another reason is current behavior allows user to not thinking about unplanned disconnection from devices by whatever reasons (power outage, wifi router reboot, etc)
I guess, it is not a problem to add a parameter to tell the lib keep the connection and subscription alive, which may be useful in case user not going to discover new devices, but it’ll take some time to test and think about the second issue above.
- Pavel
I would be happy to give up device discovery and test it out. All of my network devices are on the static lease list and get assigned the same IP each time.
Thanks
@robinson I’ve just prepared all changes in the new branch keep_connection for you. Documentation is updated accordingly.
So, please feel free to test it. Any feedback is welcome =)
BTW, discovering devices works as well in case of keeping connection.
I’ve read your ir guide and figured out that new keeping connection functionality will not help to you in getting rid of delays, because you create Orvibo instance for each request.
Also, from my point of view having separate ac-turn-on.py is an extra here, since you can just execute a shell command, so I’d replace
ON:python3 /home/pi/orvibo/ac-turn-on.py
with
ON:orvibo.py -e /home/py/orvibo/ac-turn-on.ir
- Pavel
Thanks for that. I have updated the guide to reflect this. It is one less step which is great.
Since I am now using the orvibo script directly from the command line, is there something I need to keep running perhaps with a cron job that will keep the connection alive?
Thanks again
-robinson
Using orvibo from command line is just the same you did with a separate file - creates instance, sends request, destroys instance on exit.
I’m afraid, I can’t get you a simple solution how to keep connection without extending lifetime of Orvibo class instance.
The only thing on the top of my head is to make an orvibo daemon, which will redirect commands from OpenHab to connected devices, but as for me it’s not a beauty solution.
I know not exactly connected - but are there any firmware updates - giving a better database of devices?
Hey guys, I think I might have thought up a solution for this, and that’s a very simply HTTP server that keeps the connections alive as the module already checks whether they are subscribed, it’s a matter of not creating new instances so a http server that’s running in the background does just that.
Server is ran by specifying IP address and port.
Three GET commands are accepted:
/STATUS/_IP of plug_ /ON/_IP of plug_ /OFF/_IP of plug_
I’m completely new at this (it’s my first Python program ever) so bear with me and would love to have your feedback.
It can be found as a pull request on one of the branches (if that’s how one does these things).
DomQuixote/python-orvibo
And then pull request patch-1.
I might create a new repository and link to the original one if that’s more convenient, don’t know what is best practice.
Let me know what you think.
Hi,
I used Pavel_Cherezov’s python implementation to control my Orvio AllOne but I didn’t like the delays, so I started developing an binding for Openhab2 (IR-Blaster only for now, since I don’t have any S20) and I have a few questions regarding the communication with the device:
- AFAIK the communication is based on UDP and there seems to be no command to unsubscribe from a device, so what is meant by “keeping connection” to the device?
- Does anyone know how the subscription is handled by the Allone device? Is there a timeout or does a current subscription expire as soon as new one is received?
If anyone is interested, I think I can provide a prototype soon.
Are the AllOne UDP packets the same structure as the S20 ones? I’ve already created a PR for OH2 for an Orvibo S20 binding, it would make sense to incorporate the AllOne into the same binding if so.
I’d be happy to help you with openhab binding, but unfortunately I have no any expertise here.
Actually there are two way to send request to device(s): broadcast to udp port 10000 (can be used to discover devices in the network) and sending it to exact device ip:10000. Once connected and subscribed you can send requests to device until disconnect. But you can use subscribe to get device status (e.g subscription response last bit says if S20 switched on or off)
My cmd line app does the following:
- Discover device
- Sends subscription request
- Sends request
- Receives response
- Disconnects
As you can see it has quite a big delay between app execution and something is happened with a device.
Keeping connection allows to avoid disconnection after receiving response, but this can be used only inside other app, which will hold Orvibo instance.
Hope this help
General idea and header are the same
You may compare python code (by searching “packet.compile”) in my module.
Yes that would make sense :).
Thanks, yes this helps. If I’m not mistaken, you could skip the first step to make it faster. But the user has to provide the mac address in this case.
I looked at your code and the one from here and put together prototype to emit ir signals. Feel free to test it Prototype download.
It’s very limited for now, but works stable in my environment so far. Regarding the subscription, it only subscribes again, if you emit a signal and the last subscription was longer than 5 minutes ago. It also does not receive anything from the allone device yet.
Thing
You need to add a thing manually and provide IP and MAC-Address of the Orvibo AllOne and a folder, where the IR-Signals are saved. For example:
IP: 192.168.1.123 MAC: AB:AB:AB:12:12:12 Folder: /usr/share/signals/etc
Channels
Only the “emit” channel is working. Provide the path to the IR-Signal relative to the folder specified above.
Example to hook it to the TV Power switch
sitemap:
Switch item=TV_Power label="Power"
item:
Switch TV_Power {channel="samsungtv:tv:0f7f490:power"} String EmitIR {channel="orvibo:orviboallone:5beb:emit"}
rule:
rule "TV_Power_ON" when Item Power received command ON then sendCommand(EmitIR,"samsung_tv/power.ir") end
You’re right, first step could be skipped.
It is a great idea, and I’ll add new parameter for mac address to my python module to skip discovering in case of known MAC.
@janis have you got the link to your src code? If so, and I have time, I will start to look at incorporating some of it into the existing PR.
I can send it to you if you want, but it really is a prototype, far from production quality code ;).