[RTEX] Odroid-C2 - eMMC - Armbian Buster Kernel 5.3 - Jeedom V4

que donne ? :

$ cat /boot/armbianEnv.txt

akenad :slight_smile:

image
Il n’y a plus la ligne extraargs=, je l’ai enlevé précédement!

Ce matin j’ai également mis une clé usb classique sur l’un des ports usb pour le « charger », il me semble avoir lu que c’était nécessaire!

pour information,

en novembre 2019

J’ai installé : Armbian_19.11.3_Odroidc2_buster_current_5.3.11.7z

ce qui donne dans Jeedom Analyse → Santé :

Version OS : Linux hostname 5.3.11-meson64 #19.11.3 SMP PREEMPT Mon Nov 18 20:10:57 CET 2019 aarch64 GNU/Linux [10.2]

l’ajout de overlays=uartA dans /boot/armbianEnv.txt faisait monter /dev/ttyAML1

Je viens de mettre à jour (apt update et apt upgrade)

ce qui donne dans Jeedom Analyse → Santé :

Version OS : Linux jeedom3 5.4.28-meson64 #20.02.8 SMP PREEMPT Mon Mar 30 09:12:52 CEST 2020 aarch64 GNU/Linux [10.3]

équivalent je suppose à l’installation direct de :
Armbian_20.02.8_Odroidc2_buster_current_5.4.28.7z

et /dev/ttyAML1 ne monte plus !

Linux Kernel est passé de 5.3 à 5.4 ce qui pourrait expliquer que ce qui fonctionnait ne fonctionne plus pour l’instant.

akenad :slight_smile:

Merci pour toutes ces infos, je reste à votre écoute si vous avez du changement sur ce point.
En ce qui me concerne, je reprends un projet qui consistait à installer un odroid C2 dans un boitier au format DIN, incluant un bus en fond dans lequel je fait transiter des signaux du GPIO (I2C, principalement pour le moment), d’autres modules en développement se connectent sur le même principe sur le coté pour piloter des IO (en 12V, dimmable ou non). J’essaye d’adapter au mieux Jeedom pour l’auto-consommation.

Hello

J’ai essayer ta méthode d’installe Akenad

Sauf que j’ai un souci avec le bluetooth BLE

En debug, voici la fin du fichier :

Citation
Traitement des actions diff?r?es (<< triggers >>) pour libglib2.0-0:arm64 (2.58.3-2+deb10u2) …
Aucun fichier schéma trouvé : aucune action effectuée.
Requirement already satisfied: pyudev in /usr/lib/python3/dist-packages (0.21.0)
Requirement already satisfied: pyserial in /usr/lib/python3/dist-packages (3.4)
Requirement already satisfied: requests in /usr/lib/python3/dist-packages (2.21.0)
Collecting pybluez
Downloading https://files.pythonhosted.org/packages/08/9f/e9d93b266d2d1ea988780a52a696073ba0a65df65a532165fdf6ff90d0ed/PyBluez-0.23.tar.gz (97kB)
Building wheels for collected packages: pybluez
Running setup.py bdist_wheel for pybluez: started
Running setup.py bdist_wheel for pybluez: finished with status ‹ error ›
Complete output from command /usr/bin/python3 -u -c « import setuptools, tokenize;file=‹ /tmp/pip-install-tfry4qbt/pybluez/setup.py ›;f=getattr(tokenize, ‹ open ›, open)(file);code=f.read().replace(’
', ’
');f.close();exec(compile(code, file, ‹ exec ›)) » bdist_wheel -d /tmp/pip-wheel-x4ds3ka1 --python-tag cp37:
Traceback (most recent call last):
File «  », line 1, in
File « /tmp/pip-install-tfry4qbt/pybluez/setup.py », line 132, in
cmdclass={‹ bdist_wheel ›: impure_bdist_wheel},
File « /usr/local/lib/python3.7/dist-packages/setuptools/init.py », line 144, in setup
return distutils.core.setup(**attrs)
File « /usr/lib/python3.7/distutils/core.py », line 134, in setup
ok = dist.parse_command_line()
File « /usr/lib/python3.7/distutils/dist.py », line 483, in parse_command_line
args = self._parse_command_opts(parser, args)
File « /usr/local/lib/python3.7/dist-packages/setuptools/dist.py », line 925, in _parse_command_opts
nargs = _Distribution._parse_command_opts(self, parser, args)
File « /usr/lib/python3.7/distutils/dist.py », line 545, in _parse_command_opts
if not issubclass(cmd_class, Command):
TypeError: issubclass() arg 1 must be a class


Impossible de lancer le plugin bluetooth jeedom

Ma cle bluetooth est une ASUS BT400

Merci

Hello

Sauf que ce RTEX ne traite pas du bluetooth.
tu devrais ouvrir un nouveau sujet avec le tag plugin-blea
de plus le log fournis n’est pas un debug mais le log de l’installation des dépendances qui est incomplet pour statuer.

akenad :slight_smile:

Bonjour @akenad,

Je suis intéressé par ta solution pour monitorer la température de mon Odroid N2 mais je n’ai pas tout a fait bien compris, est-il possible de le faire en passant par un script sans passer par le plugin monitoring2 ?

Bonjour @simbod38,

Voir ici : [RTEX] JeedomSmart Stretch - ODROID-C2 Armbian - Page 3 - Forum Communauté Jeedom

akenad :slight_smile:

Merci pour ces infos,

Par contre les 2 commandes ssh pour récupérer la température ne fonctionnent pas… J’imagine que du coup la méthode avec le plugin monitoring Officiel ne fonctionnera pas non plus (je suis sous armbian en kernel 5.4)

ça fonctionne sur un Odroid-C2 :
$ cat /etc/armbianmonitor/datasources/soctemp

et pour passer par un script un lien officiel est indiqué dans ce sujet plus haut : [RTEX] Odroid-C2 - eMMC - Armbian Buster Kernel 5.3 - Jeedom V4 - #12 par akenad

akenad :slight_smile:

Merci pour ta réponse, j’ai également testé avec le plugin monitoring officiel mais la valeur renvoyée est 0

Pour apporter un complément, j’ai creusé un peu la chose et j’ai obtenu ma réponse sur le forum d’armbian :

"Les relevés de température AFAIK ne sont pas encore pris en charge dans le noyau moderne, c’est pourquoi le script génère des erreurs. (nous ne pouvons que corriger armbianmonitor pour ne pas afficher d’erreurs à ce stade, mais pas vraiment critique)

Le noyau moderne est toujours un domaine de développement et on devrait être content que vous n’ayez pas besoin d’utiliser un stock 4.9.y obsolète

Le noyau moderne est en développement et il le restera encore plusieurs mois, avant de pouvoir dire que son support est arrivé à maturité. Jusque-là, beaucoup de choses ne fonctionneront tout simplement pas ou ne fonctionneront pas mal. Mais le noyau est dans une forme utilisable."

La traduction n’est peut-être pas parfaite :grinning:

Oui, il y a des différences de hardware entre un Odroid-C2 et un Odroid-N2, et les fonctionnalités apportées en fonction des différentes versions de kernel disponibles sous Armbian pour chacun sont différentes aussi. C’est pourquoi je t’invites à ouvrir un nouveau sujet dédié pour l’Odroid-N2 ou utiliser le sujet sur l’Odroid-N2 déjà existant.

akenad :slight_smile:

Bonjour,

Juste pour info, le plugin monitoring remonte l’info du proc (Odroid-N2) si c’est ce que tu cherches.
image

image
Stef.

Bonjour,

Merci du retour, mais ton exemple n’est ni de l’Odroid-C2 ni de l’Armbian.
Comme je viens déjà de le demander, j’apprécierais que la suite se fasse sur un autre sujet.

akenad :slight_smile:

Bonjour @akenad

Merci pour ce tuto clair et détaillé qui m’a aidé pour ma nouvelle installation.
J’ai donc installer sur mon Odroid C2 l’image Armbian_20.02.8_Odroidc2_buster_current_5.4.28
Tout va bien sur mon Jeedom, par contre je rencontre un problème avec ma PiZigate et le port GPIO.
Lorsque je fais "gpio -v" j’obtiens

gpio version: 3.2
Copyright (c) 2012-2017 Gordon Henderson, 2017-2020 Hardkernel Co., Ltd.
This is free software with ABSOLUTELY NO WARRANTY.
For details type: gpio -warranty

ERROR : file not found.(boardrev)
ODROID Board Details:
  Type: ODROID-C2, Revision: 01, Memory: 2048MB
  Maker: Hardkernel, Chip-Vendor: AMLogic
  * Device tree is enabled.
  *--> Hardkernel ODROID-C2
  * Root or sudo required for GPIO access.

Wiring Pi ne détecte pas correctement la révision de ma carte qui pourtant est bien la dernière version qui existe c’est à dire rev0.2 20171114.

En fonction de la révision de la carte, certains Pins du GPIO n’ont pas la même configuration, et comme il applique celui de la révision 1, les Pins 8 et 10 ne sont pas attribués, alors qu’ils devraient être en RX et TX, et en mode ALTx.
Cela ce confirme quand je fait "gpio readall" les Pins 8 et 10 de la carte n’ont pas de mode

image

J’ai cherché partout comment trouver une solution, mais je sèche…
As-tu déjà rencontré ce problème ? As-tu une idées ?

Bonjour @olivr2s,

Pour utiliser l’interface série du GPIO, bien suivre mon premier post.
En particulier :

  • utiliser l’image indiquée (kernel 5.3 et non pas Kernel 5.4)
  • overlays=uartA

akenad :slight_smile:

@akenad
Mince, j’avais pas vu ton post du 4 avril concernant le Kernel.
Donc il faut que je refasse une installation avec un kernel 5.3 maxi et évite de faire une apt-get update et apt-get upgrade pour ne pas passer en kernel 5.4 tant que le problème est présent ?

You’ve got it !

(Apt update ok mais pas apt upgrade)

akenad :slight_smile: