Yio Remote Community

Ideas for remote implementation

I cross compiled Qt for the Pi.

You can use the buildroot config to create an OS. Or I can upload the image file so you can download it.

After hours of compilation I got an error “invalid conversion from ‘xcb_window_t {aka unsigned int}’ to ‘EGLNativeWindowType {aka void*}’”. This error can be googled on several sites, reason is unclear.

Would be great if you can upload the image.

@ChristianRiedl Sure. I’ll upload the image after work today.

Hey! Here is a link to the buildroot image:

Before you burn it to the SD card, don’t forget to change the wpa supplicant file to set your wifi credentials:
/etc/wpa_supplicant/wpa_supplicant-wlan0.conf

Otherwise you can access the Pi via serial if you have a uart to USB converter and change the config.txt and cmdline.txt on the boot partition.

username is root and password is yioremote.

Thanks a lot. I think it is good when we work on the same image and Qt Version.

Indeed. Hope you managed to make it work.

I transfered it on Windows 10 with “Etcher” to the SD-card. But it stops booting after some seconds.
Without displaying any information on the HDMI display.

I also tried to replace config.txt against a default one, containing only hdmi_safe=1. No success.

Which tool do you use to transfer the .img ?

I also use Etcher, but on a Mac. Shouldn’t make a big difference.

Have you replaced also the cmdline.txt with the default one? You’ll need to do that to see something on the HDMI display.

I modified config.txt (like in my working Full Raspian image) :
#empty file

and cmdline.txt :
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait splash plymouth.ignore-serial-consoles

Now I see on the HDMI monitor a boot log. But PI seems to stop during setup of the network.
(I tried several variants of the cmdline.txt).

I am not able to modify on Windows 10 wpa_supplicant.conf, I can only read the Linux file system insite the .img file. But I think PI should boot even if the SSID is not correct.

But I found general differences in wpa_supplicant.conf between your image and my working (Full Raspian) image, maybe this is the problem.

Wlan config in my working image :

/etc/wpa_supplicant directory contains 3 shell files (action_wpa.sh, functions.sh, ifupdown.sh)
and this /etc/wpa_supplicant/wpa_supplicant.conf file :
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=AT
network={
ssid=“RICNET”
psk=“xxxxxxxxx”
}

Wlan config in your image :

/etc contains a wpa_supplicant.conf file :
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
key_mgmt=NONE
}

and /etc/wpa_supplicant directory contains only a wpa_supplicant-wlan0.conf :
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
key_mgmt=WPA-PSK
ssid=""
psk=""
}

I am sorry that I torture you with my problems. Unfortunately, I am very weak with Linux.

The boot process will wait a minute or two for the network, if it is not successful it will continue anyways. I suggest you wait a bit longer.

I am using systemd/networkd for the networking and not the default Raspbian version. That is why the setup and files are different.

I’ll see if I have time in the weekend to do a quick bash script that copies the config over from the boot partition so you’ll be able to place the wifi config file on the boot partition next to config.txt

@marton
Waiting a bit longer was not successfull. The PI crashed during booting after a few seconds. Green LED switched off.

So I decided to go another way. I created Qt 5.12.3 and QtCreator from the sources on the PI Zero. It took nearly a week but today it finished and I now I am able to run successfully my version with the entities and the integrator DLL (.so) with my MQTT interface on the PI Zero.

For this purpose I also implemented a YIO hardware simulator. It has a simple UI which simulates the buttons, ambient light, voltage, proximity, gesture etc. The simulator is a websocket server and in main.cpp it requires only a small change. Maybe it is useful for you to to test in your development environment :

#ifdef __sim__
    qmlRegisterType<SimDisplayControl>("DisplayControl", 1, 0, "DisplayControl");
    qmlRegisterType<SimInterruptHandler>("InterruptHandler", 1, 0, "InterruptHandler");
    qmlRegisterType<SimHaptic>("Haptic", 1, 0, "Haptic");
    qmlRegisterType<SimBattery>("Battery", 1, 0, "Battery");
    qmlRegisterType<SimProximityGesture>("Proximity", 1, 0, "Proximity");
#else
    qmlRegisterType<DisplayControl>("DisplayControl", 1, 0, "DisplayControl");
    qmlRegisterType<InterruptHandler>("InterruptHandler", 1, 0, "InterruptHandler");
    qmlRegisterType<drv2605>("Haptic", 1, 0, "Haptic");
    qmlRegisterType<BQ27441>("Battery", 1, 0, "Battery");
    qmlRegisterType<ProximityGestureControl>("Proximity", 1, 0, "Proximity");
#endif   

I also implemented a HomeAssistant simulator, as I have no home-assistant environment.
You have merged the dev branch into the master branch. If you want I can create a branch with my solution, when you give me then necessary rights. Of course I would update my solution to your latest version.

The green LED is turned off by a script early on boot to conserve power. That’s normal behaviour. I’ve tested the image and it works for me.

However I’m happy you managed to get it work at the end.

I’ll look at the simulator and try it out!

@marton :confused:

You are quite fast. I am a bit disappointed that you use only a part of my proposal.
I expected some kind of discussion. I invested a lot of time, because I planned to add more functionalty like media player.

Of course I have low Qt skills, but a lot of experience with software product development.

What is wrong with my proposal, especially the lightentity object ?
One of the nice things of open source projects was that I learned a lot discussing different solutions.

Hi @ChristianRiedl,

I haven’t used everything yet. I’m not as experienced as you with software development, and I would like to understand how things work. So I am adding things one by one.

There is nothing wrong with your proposal. But your suggestions requires a bit more change in the code. I added some basic things but at the same time I looked at how I did it and removed the unnecessary stuff that I added back when I started.

Sorry I haven’t started discussion before implementing your ideas. Let’s start then conversation about how we imagined the system.

Let us continue discussion per email, it is easier

ric@rts.co.at

@ChristianRiedl I am trying to implement the plugin loading in the app but getting these errors when I try to load the plugin:

Error loading plugin "Cannot load library /usr/bin/yio-remote/plugins/homeassistant.so: (/usr/bin/yio-remote/plugins/homeassistant.so: undefined symbol: _ZN13HomeAssistant10initializeEiRK4QMapI7QString8QVariantE)"

What I am doing wrong? Could you help me out? Thanks!

Nevermind, got it to work :slight_smile:

We should try to minimize the dependencies between the integrator dll’s and the remote app. Best way is to use only interfaces. I am working on an improvement, but currently I am quite busy with other things.

Thank you @ChristianRiedl for looking at it! No rush!

@marton
I am really happy to see that you also implement the light object. I think it is nice that there is one object representing the standard light.

In the meanwhile I made some performance tests to see the difference between accessing properties like brightness directly or via QVariantMap properties (which in fact means lookup by a string).

The first surprising result of my perf tests was that a normal PC is in this case about 50 to 100 times faster than the PI Zero. Bad news for my Google Chrome ambitions.

Using light.brightness is about 3 - 4 times faster than light.attributes.brightness. (on the Pi Zero 43 vs 160 microseconds). Not a really big difference.

I also tested the performance difference between testing feature bitmap and feature string list. Bitmap is about 4 times faster than string list. But the bigger advantage is that an Enum is more intellisense-friendly than a string. I always try to avoid working with strings as it is more prone to tip errors. And currently the light object does not show the available features.

It is also suboptimal that the integrator has to pack all the dynamic attributes into a QVariantMap before updating the entity. We could avoid it by introducing a “LightInterface” which allows the integrator to set the properties directly. In this case updating the entity would be about 5 times faster. But I’m not sure if that pays off.

I also noticed that you removed the possibility that the features are determined by data delivered by the integration hub. It was comfortable for the users, but probably most integration hubs do not deliver such information. So specifying the features in config.json is also sufficient.