Controle IP Ampli Home cinema Pioneer

[iHabitation]

Bonjour,
Quelqu'un a-t-il déjà réalisé un connecteur vers ampli Pioneer?
Le protocole est ici en attaché:
http://www.awe-europe.com/documents/Cont...for_CI.xls

Si quelqu'un l'a déjà implémenté, je suis intéressé pour un export/import.

Merci par avance.

[iHabitation]

Bon je me réponds à moi même.
Ok pour le contrôle basique de l'ampli Pioneer en IP, par contre impossible de lire la moindre trame..., il faut dire que la méthode glanée dans le manuel et sur le forum n'est pas vraiment intuitive.

je charge un javascript:

Code :

var retour = trame;

et une fois sur d'eux j'ai un beau message de refus de connection alors que les commandes fonctionnent toujours.
j'ajoute un

Code :

ldprint();

au js pour tenter un debug, mais le debugger semble ne plus fonctionner j'arrive sur la page d'acceuil de la nouvelle interface web (sur win et mac et quel que sot le navigateur).

je tente une commande simple: réaliser une commutation de l'alimentation de l'ampli en JS, ne fonctionne pas:
[ATTACH=CONFIG]148[/ATTACH]
Et si j'ajoute à la commande JS de commutation:

Code :

var retour = trame;

j'ai le message d'erreur suivant:
[ATTACH=CONFIG]147[/ATTACH]

De plus il est impossible de savoir si "trame" existe, a une valeur, idem pour "retour", aucun affichage n'est possible ou alors la méthode est tellement obscure que je n'ai pas réussi à la trouver?
J'ai essayé de trouver qqc dans le WIDO mais rien à afficher.
Si je déclare une variable globale "retour" (en passant par la section automates, notez déjà que c'est pas intuitif), il est impossible également d'afficher cette variable.

Alors quelle est la méthode?, variable globale, variable locale à l'équipement? comment parser une chaine en JS lorsqu'on ne peut même pas afficher la valeur de cette chaine?

Merci pour vos réponses.

[Domo]

Salut Christian,

Il faut bien penser à redémarrer le connecteur à chaque modification du JS. Le fait de charger le JS via l'équipement plutôt que depuis le connecteur permet de le redémarrer automatiquement.

Normalement si tu écris

Code :

var retour = trame;
ldprint("trame : " + retour);

devrait fonctionner même sans créer de variable retour dans l'équipement.

edit -----

Par contre j'ai le même problème que toi. Impossible d'afficher le débugueur avec la nouvelle interface web.

Donc si tu crées une variable retour dans l'équipement tu dois la retrouver dans le DS et pourvoir l'afficher.

As tu bien pensé à déclarer le caractère d’échappement de fin de trame? En l’occurrence dans ton cas <CR+LF>

Christophe

[iHabitation]

Merci pour ton retour Christophe,

J'ai bien le caractère de fin de trame ainsi que celui de fin de trame reçu comme décrit dans le protocole Pioneer:
[ATTACH=CONFIG]149[/ATTACH]

Mais dans le DS je ne peux toujours pas afficher de variable, elle n'apparait ni dans l'équipement ni dans les variables...

[ATTACH=CONFIG]150[/ATTACH]

Il faut noter au passage qu'il y a un Bug lorsqu'on choisit une commande "Commutateur d'alimentation" compatible appli iOs, elle apparait avec le nom "Muet" dans le DS...

@+

[Domo]

iHabitation a écrit :Merci pour ton retour Christophe,

Mais dans le DS je ne peux toujours pas afficher de variable, elle n'apparait ni dans l'équipement ni dans les variables...

@+

Ta capture montre les actions et non pas les feedback. As-tu vérifié que ta variable n'était pas visible dans la partie retour d'état du DS.

Christophe

[iHabitation]

Effectivement, dans la partie retour d'état, la variable est disponible.
Je commence un peu à cerner le fonctionnement de l'IP bidir.

Par contre, je n'arrive pas à utiliser la variable "trame" dans un équipement. Cela me servirait par exemple pour avoir une variable mise à jour pour chaque état de l'ampli.

Code :

?V
var volume = trame;

ou

Code :

?P
var power = trame;

etc...

mais j'ai l'erreur suivante:
[ATTACH=CONFIG]151[/ATTACH]

Cela me permettrait d'avoir un vrai retour d'état sur chaque paramètre de l'ampli.
J'ai donc déchargé le JS du connecteur (sinon retour contenait en permanence la dernière trame).

A moins que je me trompe sur la durée de vie des variables locales déclarées dans un équipement???, des idées la dessus?

[Domo]

Salut,

Dans ton javascript tu mets quelques choses dans ce genre

Code :

var retour = trame;


var typeData = retour.substr(0,2);
var data = retour.substr(3);


switch(typeData)
{
    case 'PWR':
        power = data;
        
    break;
    
    case 'VOL':
        volume = data;
        
    break;
}

Tu crées tes variables power et volume dans l'équipement.

Tu crées tes actions getVolume et getPower avec comme commande en ASCII ?V et ?P

Tu penses à redémarrer ton connecteur pour faire la jonction entre les variables du JS et ceux de l'équipement et normalement ça devrais fonctionner.

Christophe

[iHabitation]

Super, merci.
Par contre ça ne peut pas être adapté aux "entrées" car le typeData fait seulement 2 caractères.
Est-il possible de lancer les commandes de mise à jour (getpower et getVolume par exemple) au démarage de la télécommande?
@+

[Domo]

iHabitation a écrit :Par contre ça ne peut pas être adapté aux "entrées" car le typeData fait seulement 2 caractères.

C'était juste un exemple pour power et volume. Il te suffit maintenant de trouver le bon moyen d’interpréter toutes les autres valeurs.

iHabitation a écrit :Est-il possible de lancer les commandes de mise à jour (getpower et getVolume par exemple) au démarage de la télécommande?

Aucun intérêt puisque les valeurs sont en permanence à jour car comme indiqué dans la doc du protocol à chaque action l'ampli te renvoie une réponse avec la valeur mise à jour.

Christophe

[iHabitation]

C'est donc un cas de RTFM...
par contre existe-t-il une commande pour redémarrer un connecteur régulièrement, histoire d'éviter que des erreurs viennent le bloquer dans une config salon par exemple?