search

andyboeh / mediola2mqtt

Mediola MQTT Gateway
11 stars 13 forks source link

Does not start at all on HA 2021.8.8 x86 VM #5

Closed rorso closed 2 years ago

rorso commented 2 years ago

I have a fresh HA install in a VM (the "virtual box" image from https://www.home-assistant.io/installation/linux) added FTP und SSH addons to get access to the VM created a /addons/mediola2mqtt folder uploded the project files into this folder

The "local addon " shows up and can be "installed". At least it shows as "installed" after quite a while

Changed the config file to

mediola:
  host: 192.168.2.208
  password: ''
mqtt:
  host: 192.168.2.210
  port: 1803
  username: ''
  password: ''
  discovery_prefix: homeassistant
  topic: mediola
  debug: true
blinds: []
buttons: []

after saving the config I tried to start the addon. It seemingly does, but refreshing the page shows it as "stopped". Log states a problem running "bashio"

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
exec: fatal: unable to exec bashio
: No such file or directory
[cmd] /run.sh exited 127
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.

however /usr/bin/bashio is present, looks reasonable and has permission 755.

Same error when I try to execute ./run.sh from ssh -> : No such file or directory bashio

If I try to run the python script by hand as shown in run.sh: python3 -u ./mediola2mqtt.py

it moans the paho library as missing - presumably because the missing "S6" environment.

System Health

version core-2021.8.8
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.9.6
os_name Linux
os_version 5.10.53
arch x86_64
timezone Europe/Vienna
Home Assistant Cloud logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | ok
Home Assistant Supervisor host_os | Home Assistant OS 6.2 -- | -- update_channel | stable supervisor_version | supervisor-2021.06.8 docker_version | 20.10.6 disk_total | 30.8 GB disk_used | 4.0 GB healthy | true supported | true board | ova supervisor_api | ok version_api | ok installed_addons | Visual Studio Code (3.6.2), Check Home Assistant configuration (3.8.0), SSH & Web Terminal (9.0.1), FTP (4.2.1), Mediola to MQTT (0.3)
Lovelace dashboards | 1 -- | -- resources | 0 views | 4 mode | storage
rorso commented 2 years ago

probably fixed

the following files have CRLF line endings instead of LF line endings:

config.json
PKGBUILD
mediolamanager.py
mediola2mqtt.py
Dockerfile
run.sh

after converting them to LF endings, the plugin starts without complaints.

The HA 2021.8.8 x86 VM seems to be a little picky about that.

andyboeh commented 2 years ago

Thanks for the information - this needs to be fixed, so I'm reopening it. I use Linux exclusively, there is no real reason for why there are CRLF line endings!?

andyboeh commented 2 years ago

I just checked the files locally and the download of the ZIP archive: Only config.json had mixed line endings, I converted that. All the other files had Unix line endings.

rorso commented 2 years ago

I cannot tell where that came from either. I'm on Linux too. But I hat a few tries until I found a solution to run HA in a VM on my Synology NAS. So it could have get mangled on the way, passing several editors and an FTP/SSH transfer.

Btw. I still struggle to get it running reasonable with my Mediola V5 (no plus) and Elero BiDi Blinds. The Up and Down buttons do just a single step, not a full up or down. States are "guessed", not read, but that's certainly a fault on the V5 gateway that does not listen to the Sensor Answer. V5 cannot get set to "elero" Sensor Mode so it essentially operates in Uni mode, despite of the BiDi actuators.

The V5 talks on UDP 1901. That can be set in the config and it lists a few inbound packages but they all do not belong to operating the blinds but rather get general AIO data and an advertizing of a "Mediola Server" that I did start elsewhere. Those two seem to find each other.

I have captured the communication with the V5 and the Mediola IQONTROL app, in case you are interested. A few differences compared to V4 like a different format of the GetSI response that causes mediolamanager.py to crash on a missing value, correctly formatted JSON response when called with "/cmd/" instead of "/command". Such things.

/cmd?XC_FNC=SendSC&type=ER&data=xxyy

xx = channel (00 - 0F)
yy = command

Commands

01  ??
02  Stop
03  Step Up
04  Step Down
05  ??
06  ??
07  ??
08  Full Up
09  Full Down
0A  Ventilation
0B  Shading

"Ventilation" does only work from "full-down" state that unfortunately does not get responded properly, so it's virtually impossible to do a "down and ventilation" combination - even with the native MEDIOLA App. I guess, "Shading" has to be configured to some intermediate position with the manual remote. I don't use this.

Best regards, Robert

andyboeh commented 2 years ago

According to the manual, the commands are as follows:

0x00    Down/Off
0x01    Up/On
0x02    Stop
0x03    Step Up
0x04    Step Down
0x05    Manu Mode
0x06    Auto Mode
0x07    Toggle Mode
0x08    3s Up
0x09    3s Down
0x0A    Double Tap Up
0x0B    Double Tap Down
0x0C    Start Learning
0x0D    On Pulse Move
0x0E    Off Pulse Move
0x0F    AS_Close
0x10    AS_Move

0x00/0x01/0x02 are thus what I chose.

There is an ongoing issue for the v6, did you read through it? #4 and #3

rorso commented 2 years ago

Thanks for sharing this table. Obviously your manual is more comprehensive than mine. The best I got was an outdated API documentation from September 2014 from the mediola website that does not cover "elero" at all.

I can confirm that the current IQONTROL for Android (not IQONTROl NEO) does send

http://192.168.2.208/cmd?XC_FNC=SendSC&type=ER&data=0109&_=1630072735789

for a "full down" on channel 1 and likewise

http://192.168.2.208/cmd?XC_FNC=SendSC&type=ER&data=0108&_=1630072868836

for a "full up" to my V5 AIO-Gateway and I confirmed that working as expected from a browser. The &_=1630072868836 is a UNIX timestamp value of unknown function. Maybe used to internally sort commands in the queue.

Neither XC_FNC=refreshER&adr=01 nor XC_FNC=refreshSC&adr=01&type=ER does anything meaningful with my V5 on newest firmware release 1.0.31 other than reply

{XC_ERR}{"CODE":"010000"}

or

{"XC_ERR":{"CODE":"010000"}}

depending on how I call it as /command?XC_FNC=... or rather /cmd?XC_FNC=...

My receiveres are of type elero Combio-868 JA Pulse bidirectional which may make a difference in both reaction and response with each of the commands as we don't see what's really going on on the air interface. Things that may be known to the AIO-Interface but wich are not obvious on the API calls.

A current GetStates gets me

{
   "XC_SUC":[
      {
         "type":"EVENT",
         "adr":"FF",
         "state":"0"
      },
      {
         "type":"ER",
         "adr":"01",
         "state":"0000"
      },
      {
         "type":"ER",
         "adr":"02",
         "state":"000D"
      },
      {
         "type":"ER",
         "adr":"03",
         "state":"0000"
      },
      {
         "type":"ER",
         "adr":"04",
         "state":"0000"
      },
      {
         "type":"ER",
         "adr":"05",
         "state":"0000"
      },
      {
         "type":"ER",
         "adr":"06",
         "state":"0000"
      },
      {
         "type":"ER",
         "adr":"07",
         "state":"0000"
      },
      {
         "type":"EVENT",
         "adr":"01",
         "state":"1"
      }
   ]
}

which is wrong as 01-02 are full down, 03-06 are full up, 07 is partway down, ... But it's wrong on IQONTROL too for the same reason.

The communication against AIO V5 is quite sparse with IQONTROL. From starting the app till "send full down" there are just a very few

http://192.168.2.208/info?_=1630072016068
http://192.168.2.208/cmd?XC_FNC=getStates&_=1630072083046
http://192.168.2.208/info?_=1630072083060
http://192.168.2.208/cmd?XC_FNC=SendSC&type=ER&data=0109&_=1630072735789

No attempt for any "refresh" so I did learn about this command just from your project.

I can supply results to all of those queries, but I prefer not to post them public as they contain location, WLAN and serial information. But it may help that /info tells me that "hwv":"E1" what identifies my V5.

getSI is not issued but does work. However it results in a different structure than on V4 which causes mediolamanager.py to break.

And I'm still researching whether any of the "Sensor Modes" might change anything when dealing with elero blinds. No luck so far.

andyboeh commented 2 years ago

Thanks for the detailed report. I don't know what you mean with "Sensor Modes"?

The table is an extract of the official v5 API documentation, available after registration at http://api.mediola.com/v5. The documentation also contains information on the different receivers and how they are configured, maybe we need to start looking at this information.

rorso commented 2 years ago

I did apply for a login to this page quite a while ago but just got an automatic reply "don't call us, we call you". Maybe they are a little picky who gets granted access.

So far I'm left with their published but old PDF at https://www.mediola.com/support-docs/API_AIO_GATEWAYS-All.pdf, reverse engineering of the network traffic and some peeks and pokes.

Regarding AIO-Sensor modes

Pherhaps it makes sense to talk this over in a different discussion or private session as it is already far off the primary (and solved) "does not start" problem and much more "how can I participate".