bon après-midi,
Il serait intéressant de récupérer l’application d’alerte de bourrage pour Android.
Un boîtier avec un bel extérieur serait également intéressant. avec de la place pour une batterie externe et un adaptateur 220v vers usb et une sirène. sirène avec minuterie de 3 minutes.
Ce serait un complément idéal pour les alarmes sans fil en ville.
Aussi pour l’extérieur du noyau urbain pour éviter les vols par inhibiteurs lorsque les propriétaires dorment dans la maison. Je ne sais pas si tout cela serait possible avec aussi la connexion câblée à un hub. Merci
Ensuite, je sais que les spécifications ne sont pas ouvertes, mais communiquer plus auprès des éco-système (ex: Jeedom) car faut pas se voiler la face, personne n’utilise le RFPlayer depuis l’interface Java :-).
Pour finir, sur l’X2D, pour mes volets je n’ai que monter / descendre… Je dirais qu’il manque les instructions de stop mais également un setPosition, et un retour de l’état… La box Tydom me les retourne.
Bonjour,
Je viens d’acquérir votre nouveau RFPlayer, il fonctionne très bien !
En suggestion d’évolution : inclure les sondes La Crosse Mobile-alerts.
Merci !
Merci pour votre retour, nous allons voir si ce protocole est facilement implantable.
Si vous pouviez nous fournir une référence de sondes ce serait parfait.
Pour le moment nous étudions le code du RF Player. Nous ne savons pas encore à ce stade si nous aurons la place de rajouter de nouveau protocole car le firmware est a 92% donc quasiment full. On va commencer par faire du nettoyage en espérant gagner de la ressource. Ça va forcément prendre du temps mais on a bon espoir de récupérer de la place. Donc il va falloir être patient
Egalement très intéressé par une compatibilité avec les produits La Crosse.
J’utilise notamment les sondes suivantes :
MA10300
MA10700
MA 10402
Ces sondes sont en 868 Mhz, le rfxcom ne peut pas les prendre en charge. Le RF Player est la seule solution pour espérer se passer un jour de la passerelle La Crosse MA 10001, avec laquelle les possibilités d’interfaçage sont limitées (j’extrait actuellement sur une page HTML).
Meme utilisation que laurent.da.col
Mes sondes : MA10200, MA10200, MA10650, MA10300, MA10660, MA10421.
Egalement très intéressé par une compatibilité avec les produits La Crosse.
Bonjour,
J’ai des petites suggestions pour les évolutions de firmware:
Je ne crois pas qu’on puisse pour le moment récupérer les données d’associations des différents périphériques ni même connaître pour chaque protocole, les canaux qui ont été associés. Une commande « STATUS TRANSMITTERS [TEXT|JSON|XML] » permettant cela serait intéressante.
Tant qu’à faire cela, il serait également intéressant de pouvoir charger les données d’association exportées avec la commande suggérée plus haut dans un nouveau module (en cas d’achat d’un nouveau module après une panne ou d’un RAZ). Après, je n’ai pas regardé le fonctionnement en détail des protocoles, un changement de l’adresse Mac suffit peut-être ?
J’ai vu dans l’API qu’il y avait moyen d’envoyer des trames au format RFLink mais la doc n’est pas claire à ce sujet sur la façon de faire (après, ma spec est vieille : API Specifications V1.8 1/12/2016). Es-ce vraiment possible ? J’en profite, existe-il une version plus récente de la spécification ?
Dans l’optique de gagner un peu de place dans le firmware et de limité les flux de données sur l’USB, j’ai vu qu’il y avait pas mal de commentaires envoyés par le module (" Most 433Mhz devices", " Very small noise", " A bit noisy", …), j’imagine (peut-être à tort) que ça doit prendre un peu de place dans la section TEXT du firmware pour à mon avis pas grand chose. Si c’est spécifié, l’appli client peut contenir l’information. Une implémentation d’un client de référence dans un langage quelconque pourrait même renvoyé l’info, à charge de la communauté d’implémenter d’autres langages. De même, les unités sont remontées dans les flux, je ne pense pas que ce soit nécessaire si c’est dans la spec.
Les format HEXA et HEXA FIXED me semble inutiles. Je ne pense pas que quelqu’un les utilisent et de toute façon, il est assez simple de convertir du binaire en string HEXA. Je ne pense pas que ce soit utile d’encombrer le firmware avec ça. Après, pareil, j’imagine que c’est pas ça qui va faire gagner beaucoup de place mais bon…
En espérant que mes remarques soient pertinentes.
Cordialement
Merci pour vos retours et idées…Il y a beaucoup a faire.
Concernant le mode RFlink, de notre coté nous n’avons pas eu beaucoup d’info.
De mon point de vu c’est certainement via le mode binaire que les trames RF LINK sont envoyées.
Les autres formats sont peut etre intégrés dans des applications ou des plugins, c’est donc délicat de supprimer des fonctions ou des formats pour le moment.
Il n’a pas de document plus récent concernant l’API et c’est dailleurs avec cette base que nous travaillons.
J’ai conscience que vous devez au maximum garder une compatibilité avec l’existant. Cependant, les fonctionnalités que je pointe ne sont probablement pas utilisées. Le code natif de Domoticz utilise une communication binaire, le plugin n’utilise ni les commentaire, ni le mode hexa et je serais étonné qu’il en aille différemment pour eedomus ou jeedom. Les développeurs aillant fait leur code dans leur coin, s’ils ont utilisé ces fonctionnalités, devrait être capable de modifier leur code en conséquence. De plus, la version du firmware étant envoyée par le module, il est toujours possible de différencier le fonctionnement en conséquence et l’utilisateur peut toujours rester (ou downgrader) sur un firmware plus ancien si le code qu’il utilise ne gère pas la nouvelle version. De mon point de vue (de développeur), adapter modérément un code pour pourvoir gérer plus de fonctionnalité ne peut être que bénéfique. J’irais même plus loin, si il faut tout recodé pour un gain majeur, ça peut être acceptable (Microsoft fait ça à chaque version de DirectX). Après, ce n’est que mon humble avis, je dis ça juste pour lancer le débat
Sinon, j’ai maintenant pas mal secoué le module est j’ai vu plusieurs petit problèmes dans le firmware :
La « Sensitivity » n’est pas remonté dans le message de status radio
Dans une moindre mesure, le « FORMAT » et la LEDActivity ne sont pas remonté dans le message de status système (le format n’est de toute façon pas sauvegardé donc il vaut mieux renvoyé la commande à chaque connexion, je ne sais pas pour l’activité de la led mais c’est moins critique)
La liste des protocoles repeaters et receivers available change lorsqu’on active/désactive des protocoles. Cela ne me semble pas normal.
Alors si il faut tout recoder, le prix du RFPlayer va vraiment augmenter
Comme je l’ai dit on doit d’abord reprendre le code et faire un état des lieux. Si vous êtes développeur vous savez sûrement à quel point reprendre le code de quelqu’un d’autre prend du temps surtout quand celui ci n’est pas commenté. Une fois qu’on aura bien repris la main on saura ce qu’on peut retirer pour gagner de la place.
Par contre merci pour vos retours, il y a de bonnes pistes à creuser
Bonjour,
Y a t’il d’autres projets ?
Pour ma part j’ai des périphériques BLYSS en 868 Mhz et je suis assez frustré de ne pas pouvoir les récupérer avec le RFPlayer 1000…
De plus je pense qu’il manque le protocole X3D.
Salutations.
comme pour tous les produits GCE, les évolutions se font en fonction des demandes des utilisateurs, si il y a assez de demandes pour les protocoles que vous citez.
J’ai du Kerui qui n’est pas compatible enfin une télécommande est bien détectée sur du DOMIA mais non fonctionnelle (RTS fonctionnel mais il manque des commandes… STOP, un battant)
A mon sens la partie hardware est plutôt de bonne qualité, dommage qu’on soit bloqué par la partie software.
Pourquoi ne pas ouvrir le code source afin qu’on alimente tous les commentaires manquants ? (Ou du moins à ceux qui souhaite participer…)
Je pense qu’au final un nouveau firmwaire avec un mode « Externe » permettrait de traiter le signal depuis l’hôte serait une bonne idée. (PC/BOX domotique)
Cette solution permettrai d’ouvrir le champ des possibles pour analyser ou émettre un signal sans passer par le microcontrôleur de la clé, et je pense sans reconstruire le firmware complet.
ça va nous être utile.