I did, it has been helpful so far and I’ve mostly finished the OH2 part (setting up the thing types and channels). I now need to do the low level work in the library and I’ve noticed subtle difference e.g. discovery response for S20 is one byte longer than the response for AllOne in the link I found above.
@janis would you be able to send me one or two of your IR code files so I can test the AllOne code please?
Sure, there you go =).
They’re not zipped. Just the raw ir code.
samsung_power.json (290 Bytes)onkyo_power.json (162 Bytes)
Hi, I’m using your last orvibo.py script to test a S20 and an Allone devices.
I found this “strange” behavior.
If the S20 is offline (disconnected), if I ask the status with:
python orvibo.py -i 192.168.1.40 -x socket
I have correctly the reply: Device ip=192.168.1.40 not found.
Instead, if I ask the status with:
python orvibo.py -i 192.168.1.40 -m accf23977086 -x socket
I have the repy: Orvibo[type=socket, ip=192.168.1.40, mac=accf23977086] Is enabled: False
(like the socket is connected but off)
Another problem with the Allone:
I grab an IR code:
python orvibo.py -i 192.168.1.38 -t power0.ir
I send the IR code:
python orvibo.py -i 192.168.1.38 -e power0.ir
The send command works correcty only sometimes, the shell output is always the same:
Orvibo[type=irda, ip=192.168.1.38, mac=accf237e6008]
Done.
but trasmissions does not occur (no transmission and no red led on Allone). This is with python version 2.7.9
If I use python3 version 3.4.2 (python3 orvibo.py -i 192.168.1.38 -e power0.ir) I receive an error:
Orvibo[type=irda, ip=192.168.1.38, mac=Unknown]
Traceback (most recent call last):
File “orvibo.py”, line 554, in
d.emit(emitFile)
File “orvibo.py”, line 455, in emit
if self.__subscribe(s) is None:
File “orvibo.py”, line 299, in __subscribe
subscr_packet.compile(SUBSCRIBE, self.mac, SPACES_6, _reverse_bytes(self.mac), SPACES_6)
AttributeError: ‘Orvibo’ object has no attribute ‘mac’
Any ideas?
Thanks a lot, sorry for my english
mircomazzu, thank you for such a detailed post. I’m experiencing an EXACTLY SAME problem.
Tried it on top Ubuntu 14.04 and also fresh Raspbian install
Hi all, sorry for such a late answer.
AttributeError: ‘Orvibo’ object has no attribute ‘mac’
Actually this must be fixed with the latest commit 19 days ago. If you still have experienced the problem - please let me know.
Instead, if I ask the status with:
python orvibo.py -i 192.168.1.40 -m accf23977086 -x socket
-m and -x arguments were introduced to decrease latency between sending request and the moment it actually applied on your device. So you have to be sure you device is visible on the network and has exact mac and type you’ve passed to the script. Any value checking will mitigate the effort.
The send command works correcty only sometimes, the shell output is always the same:
Orvibo[type=irda, ip=192.168.1.38, mac=accf237e6008]
Done.
Done - meant it was sent to AllOne for
Be sure AllOne and controlled device are close enough and there is a straight visibility (for IR case).
Please also check that red circle is blinking once at the moment of emitting.
Hope this helps.
Thanks for using module and let me know if you still have any questions/problems with it.
@mircomazzu @moskovskiy82
I’ll check problem with py2.7 and py3 ASAP.
Thank you guys!
Using it together with IR Blaster. I’ve downloaded everything yesterday so the commit is supposed to be included. But still experienced the no attribute mac when running with python3. I also opened the issue on your githib. Thanks for the great work
If it helps this is what i have installed
$ apt-show-versions | grep python
dh-python:all/trusty-updates 1.20140128-1ubuntu8.2 uptodate
libpython-stdlib:amd64/trusty 2.7.5-5ubuntu3 uptodate
libpython2.7:amd64/trusty-security 2.7.6-8ubuntu0.2 uptodate
libpython2.7-minimal:amd64/trusty-security 2.7.6-8ubuntu0.2 uptodate
libpython2.7-stdlib:amd64/trusty-security 2.7.6-8ubuntu0.2 uptodate
libpython3-stdlib:amd64/trusty 3.4.0-0ubuntu2 uptodate
libpython3.4-minimal:amd64/trusty-updates 3.4.3-1ubuntu1~14.04.3 uptodate
libpython3.4-stdlib:amd64/trusty-updates 3.4.3-1ubuntu1~14.04.3 uptodate
python:amd64/trusty 2.7.5-5ubuntu3 uptodate
python-apt:amd64/trusty-updates 0.9.3.5ubuntu2 uptodate
python-apt-common:all/trusty-updates 0.9.3.5ubuntu2 uptodate
python-chardet:all/trusty 2.0.1-2build2 uptodate
python-configobj:all/trusty 4.7.2+ds-5build1 uptodate
python-crypto:amd64/trusty 2.6.1-4build1 uptodate
python-debian:all/trusty 0.1.21+nmu2ubuntu2 uptodate
python-dnspython:all/trusty 1.11.1-1build1 uptodate
python-gdbm:amd64/trusty 2.7.5-1ubuntu1 uptodate
python-ldb:amd64/trusty-security 1:1.1.24-0ubuntu0.14.04.1 uptodate
python-minimal:amd64/trusty 2.7.5-5ubuntu3 uptodate
python-ntdb:amd64/trusty 1.0-2ubuntu1 uptodate
python-openssl:amd64/trusty 0.13-2ubuntu6 uptodate
python-pam:amd64/trusty 0.4.2-13.1ubuntu3 uptodate
python-pkg-resources:all/trusty-updates 3.3-1ubuntu2 uptodate
python-pycurl:amd64/trusty 7.19.3-0ubuntu3 uptodate
python-requests:all/trusty-updates 2.2.1-1ubuntu0.3 uptodate
python-samba:amd64/trusty-security 2:4.3.9+dfsg-0ubuntu0.14.04.3 uptodate
python-serial:all/trusty 2.6-1build1 uptodate
python-six:all/trusty-updates 1.5.2-1ubuntu1 uptodate
python-software-properties:all/trusty-updates 0.92.37.7 uptodate
python-talloc:amd64/trusty-security 2.1.5-0ubuntu0.14.04.1 uptodate
python-tdb:amd64/trusty-security 1.3.8-0ubuntu0.14.04.1 uptodate
python-twisted-bin:amd64/trusty 13.2.0-1ubuntu1 uptodate
python-twisted-core:all/trusty 13.2.0-1ubuntu1 uptodate
python-urllib3:all/trusty-updates 1.7.1-1ubuntu4 uptodate
python-xapian:amd64/trusty 1.2.16-2ubuntu1 uptodate
python-zope.interface:amd64/trusty 4.0.5-1ubuntu4 uptodate
python2.7:amd64/trusty-security 2.7.6-8ubuntu0.2 uptodate
python2.7-minimal:amd64/trusty-security 2.7.6-8ubuntu0.2 uptodate
python3:amd64/trusty 3.4.0-0ubuntu2 uptodate
python3-apport:all/trusty-updates 2.14.1-0ubuntu3.21 uptodate
python3-apt:amd64/trusty-updates 0.9.3.5ubuntu2 uptodate
python3-commandnotfound:all/trusty 0.3ubuntu12 uptodate
python3-dbus:amd64/trusty 1.2.0-2build2 uptodate
python3-distupgrade:all/trusty-updates 1:0.220.8 uptodate
python3-gdbm:amd64/trusty-updates 3.4.3-1~14.04.2 uptodate
python3-gi:amd64/trusty-updates 3.12.0-1ubuntu1 uptodate
python3-minimal:amd64/trusty 3.4.0-0ubuntu2 uptodate
python3-newt:amd64/trusty 0.52.15-2ubuntu5 uptodate
python3-problem-report:all/trusty-updates 2.14.1-0ubuntu3.21 uptodate
python3-pycurl:amd64/trusty 7.19.3-0ubuntu3 uptodate
python3-software-properties:all/trusty-updates 0.92.37.7 uptodate
python3-update-manager:all/trusty-updates 1:0.196.14 uptodate
python3.4:amd64/trusty-updates 3.4.3-1ubuntu1~14.04.3 uptodate
python3.4-minimal:amd64/trusty-updates 3.4.3-1ubuntu1~14.04.3 uptodate
@moskovskiy82 @mircomazzu I’ve just fixed the bug. Please feel free to update orvibo module and test it.
Thanks you guys for reporting!
I can confirm that the problem is gone.
Thank you for your time!
Hi,
I came across exactly the issue of Mac=Unknown when run the Orvibo.py with python3. Just update the Orvibo.py as per Pavel_Cherezov instruction and confirmed it is OK now.
Btw, is there anyway to get the status of the switch updated everytime I use the physical on/off button on the S20 to control it, not by the orvibo.py script?
Btw, is there anyway to get the status of the switch updated everytime I use the physical on/off button on the S20 to control it, not by the orvibo.py script?
In short - yes, but it is not implemented 
In fact there is a possibility to subscribe and receive orvibo events, but it hasn’t completely reverse engineered yet. Moreover this feature will not be accessible from the command line, but only as python module in separate scripts.
Thanks for usage, testing and feedback!
Have a nice day
For those on OH2 I’ve added experimental (read: there will be bugs and things that don’t work as expected) support for the Allone to the Orvibo binding. You can find jar here and read the README here.
2 Likes
Thank you Pavel_Cherezov for your great work. Actually I haven’t tried to run the Orvibo script from Openhab but I actually ran it from Domoticz. And it works perfectly, except the status update as mentioned. I also tested Jeedom, where I found another Orvibo plugin and tried it. I found the Orvibo plugin of Jeedom gave feedback when turning the S20 on/off instantly, comparable to the native Wiwo app and it has the S20 status updated with both the Wiwo or physical button. However, it does not run as reliably as your script. In fact, I had to click the Jeedom switch button repeatedly until it would work.
Thanks @Pavel_Cherezov! I can confirm too, now the problem is gone.
I would have a request for your module..
Is it possible send a command to the orvibo device using only its mac address, without the ip?
For instance, to swith on a socket: python3 orvibo.py -m accf23977086 -s on
This could be usefull to bypass the dynamic ip and router setup questions..
Thanks a lot for your time
I have already had an idea to try broadcasting orvibo control packet to the network without ip address, but had no chance to try it. From my point of view this should works exactly you want.
Your request gives me a bit more motivation to try it in nearest future and update my module in case of success.
Thank you!
@mircomazzu
Seems, my assumption was correct.
I’ve pushed updated module to github already for you
Hi Pavel, I’ve tested the last 1.3 version, I’ve found some problems.
Starting, I’ve tested the command python3 orvibo.py -m accf23977086 -x socket -s on
It has swiched ON the socket (led goes blue), but the reply of the module is:
Orvibo[type=socket, ip=Unknown, mac=accf23977086]
WARNING:Orvibo@255.255.255.255:Socket switching on failed.
Is enabled: False
If I repeat the same command, second time the reply is
Orvibo[type=socket, ip=Unknown, mac=accf23977086]
WARNING:Orvibo@255.255.255.255:Socket switching on failed.
Is enabled: True
So, I’ve again the WARNING message, but now the enabled status goes True
Instead, the command: python3 orvibo.py -m accf23977086 -x socket -s off
doesn’t work, it has no effect on socket, and the reply is always (in both cases of socket in ON or OFF status)
Orvibo[type=socket, ip=Unknown, mac=accf23977086]
Already disabled.
I’ve tried to investigate again, I’ve forced ON the socket, the command:
python3 orvibo.py -i 192.168.1.40 -m accf23977086 -x socket
give me correctly
Orvibo[type=socket, ip=192.168.1.40, mac=accf23977086]
Is enabled: True
but the command:
python3 orvibo.py -m accf23977086 -x socket
give me
Orvibo[type=socket, ip=Unknown, mac=accf23977086]
Is enabled: False
The detection of status seems doesn’t work correctly without the ip in the command.
Thanks a lot !!
@mircomazzu It is very interesting results indeed 
In my network everything was as perfect as in 1.2 version.
Thank you for this report, I definitely must dig a bit deeper into this question.
Could you please tell me what OS do you use?