I believe you are correct Sir, on both systems. I will do some searching on the topic and report back to try to help others if i can find a resolution.
Thanks!
I wanted to report back with a few updates, and ask a question.
My question is do I need to g++ compile on the system that I am running?
In other words, I’ve found the Docker container, and was able to connect via console.
The container is homeassistant, and the directory is:
/usr/local/lib/python3.7/site-packages
While g++ was not available in this container, I was able to compile on a Raspberry Pi and pull the .so file off.
I then transferred that file via samba to the computer running Hassio (after renaming the old file to .sow)
At that point, I was able to copy it from the directory I could see from samba and pull it into the appropriate directory.
The trouble is something is not working as planned. After rebooting, I cannot see anything remote.send_command related, meaning the remote. prefix is missing from services on Developer Tools.
Thank you for your help!
Hello!
I was able to get this working - at least better -
I tried to compile on Ubuntu Server 20.04 and the resulting file was larger than how it compiled on the Raspberry Pi 3B+.
I did run sudo -i first this time - maybe that was it.
Anyway, the original, non-working file is 156 kb. The new working file is 188 kb.
Rebooted and remote.send_ is in services.
Edit:
I am sorry to report - the problem of random commands being properly executed or ignored still persists.
Thanks anyway!
Generally yes, because the compiler on the Rpi will generate machine code specifically for the processor it runs on. You can compile on a different machine if it has the same CPU architecture, otherwise you get into what is called a cross-compiler. It is possible you need different compile flags to build a shared library file on the Pie. I did a quick google search but couldn’t find thread on it.
Hi!
I have this problem too!
How do I go about compiling when I’m running HassOS? I don’t suppose there’s a step by step instructions to do so?
Thanks
HassOS based Home Assistant doesn’t appear to have any compiler tool chains, so your best bet would be to find a hardware platform that has the same CPU architecture and has a g++ compiler. What platform are you running HassOS on?
I’ve downloaded the hassOS image for vmware… and the server runs an older xeon cpu. Should I look up how to ssh to hassos’s host and install compiler on it?
I’m not familiar with VMware, but if it is possible to compile C code on your server (outside of HassOS image), then it may be simpler to compile the itach code there and copy the resulting shared library into say the HA config directory and then move it from there into the Homeassistant Container’s site-packages directory.
I will look that up; thanks.
Btw, did you experience this problem too:
(random itach ports not starting correctly).
I didn’t have that issue when I only had an IP2IR on my system… but as I setup more of them on my system, the latter ones couldn’t start up correctly despite trying to restart multiple times.
UPDATE:
I have a “production” system running HA using python venv, but I also have a “sandbox” Hassio (officially Home Assistant). I took the itach shared library file that I compiled on my production system and copied it to my sandbox Hassio system. Both of these systems have the same linux CPU architecture/machine (in my case $ uname -m => x86_64), so compiling on one system and copying to another should work. I ran a test to see if the itach shared library file would work within the Hassio’s Home Assistant container, and it indeed did work!!
There is a problem however that dawned on me when using Hassio that I wanted to point out. When you update say from 0.117.x to 0.118, the update replaces the old Home Assistant container with the new one and whatever files you extraneously added (like the itach shared library) to its site-packages directory will disappear after the container upgrade. The workaround for this will probably to be make the itach component a custom component as it will live under the config directory which remains intact after an upgrade.
Finally, on your question about problems with multiple IP2IR devices…I only have one IP2IR, so haven’t run into this before.
That’s great!
Ok noted; only major version? 0.117.x updates should be ok?
I don’t suppose I can get a copy of your x86_64 binary to try on my hassio?
This will hold true for any updates, major or minor.
I placed the compiled shared library file for x86_64 in the repository.
Thanks so much. I have some GC100 and iTach IP2IR units, and I think the network issues show up much more on the GC100 devices… I have switched to multiple IP2IR instead, and on top of that, I’m running 2 hassio slaves on Pis… so I’ve attached 2 IP2IR on the master, and one IP2IR each on the slaves; so far I’m not seeing any problems on my install!
@wmaker Are your changes to pyitachchip2ir still working for you in current versions of Home Assistant?
Yes I still use it. I use to run this only with HA-core in a python venv, but a few months ago I switched over to a new hassio system and have adapted things to work with it. You can read more in details here:
1 Like
@wmaker Thanks for the confirmation. I followed the instructions and was able to change out the itachip2ir.so and reboot HA.
However, I’m still having trouble sending any command but ON, when using the Services via Dev Tools. The ON command caused the IR emitter to light up red but none of the other commands do. Any ideas on how to troubleshoot this?
YAML code for reference:
data:
num_repeats: 1
delay_secs: 0.4
hold_secs: 0
command: "OFF"
target:
entity_id: remote.living_room_itach
I’ll have to admit, its actually been several years now since I set this up so I’m rusty on it.
Did you look at the HA itach documentation?
You need a “remote” in your YAML configuration. If you have it, then maybe post it and we can take a look.
This is what I have so far.
- platform: itach
host: 192.168.1.42
devices:
- name: living.room.itach
modaddr: 1
connaddr: 1
ir_count: 3
commands:
- name: "OFF"
data: "0000 006D 0022 0000 00ad 00ad 0015 0041 0015 0041 0015 0041 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0041 0015 0041 0015 0041 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0041 0015 0041 0015 0015 0015 0015 0015 0041 0015 0041 0015 0041 0015 0041 0015 0015 0015 0015 0015 0041 0015 0041 0015 0015 0015 0728"
- name: "ON"
data: "0000 006D 0000 0022 00ac 00ac 0016 0040 0016 0040 0016 0040 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0040 0016 0040 0016 0040 0016 0015 0016 0015 0016 0015 0016 0015 0016 0015 0016 0040 0016 0015 0016 0015 0016 0040 0016 0040 0016 0015 0016 0015 0016 0040 0016 0015 0016 0040 0016 0040 0016 0015 0016 0015 0016 0040 0016 0040 0016 0015 0016 071c"
- name: "INPUT HDMI 1"
data: "0000 006D 0022 0000 00ad 00ad 0015 0041 0015 0041 0015 0041 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0041 0015 0041 0015 0041 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0041 0015 0015 0015 0015 0015 0041 0015 0015 0015 0041 0015 0041 0015 0041 0015 0015 0015 0041 0015 0041 0015 0015 0015 0041 0015 0015 0015 0015 0015 0015 0015 0728"
This config looks good to me. I don’t know what the problem may be. Maybe as a test, set OFF’s data to be the same as ON’s data. If the IR LED lights up for both ON and OFF in that setup, then it kinda suggests its an IR code issue.
Circling back on this issue. You were correct, this was an IR Code issue. Some of the commands from the GlobalCache Database for Samsung have lower case letters in the hex code.
I was able to figure this out by converting the GlobalCache commands (starts with sendir) to Hex Code via iConvert, and using an online text-comparision.