Discussion :

[bacelar]

je suis desole je vois pas du tous comment faire? merci

Nous non plus, car vous n'indiquez par avec quel framework ou librairie graphique vous voulez travailler.

En faisant ce choix, vous n'aurez qu'à suivre les préconisations y afférent.

P.S.: au départ, je pensais être plus dirigiste, mais il semble que les timers d'Asio (librairie "pré-standard") n'ont pas encore trouvés leur chemin vers le standard C++.

[ludoiphone]

j'utilise Qt ou si il y as autre chose.

qu'elle sont vos proposition ?

merci

[bacelar]

https://doc.qt.io/qt-6/timers.html

[ludoiphone]

salut ,

j'ai deja un Qtimer dans mainwindow pour mettre a jour les temperatures sur l'ecran .

apres je n'arrive pas a faire tourné ma boucle pac en meme temp que celle de l'interface sur main

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
    PAC pac;
 
    std::this_thread::sleep_for(std::chrono::seconds{1});
    pac.run_pac();
 
    Consignes *m_initConsignes;
 
    do {
	QApplication app(argc, argv);
	QApplication::setOverrideCursor(QCursor(Qt::BlankCursor)); // cache pointeur Sourie
 
	m_initConsignes = new Consignes(QString("settings/consignes.ini"), QSettings::IniFormat);
	m_initConsignes ->controleConsignes();
 
	//m_initFiltre = new Filtre(QString("settings/filtre.ini"), QSettings::IniFormat);
	//m_initFiltre ->controleFiltre();
 
	MainWindow window;
 
	return app.exec();
 
    } while (1);

[bacelar]

apres je n'arrive pas a faire tourné ma boucle pac en meme temp que celle de l'interface sur main

Vous ne devez pas avoir de boucle dans PAC, c'est le timer de Qt qui fera le travail de rappel régulier.
A quoi sert la ligne 4 de votre code ????
Idem pour la ligne 5.

Il est ou le timer qui rappelle régulièrement "run_pac" ???

[kaitlyn]

Salut,

Pour la question sur les "display" oui, la finalité, c'est bien l'interface utilisateur.
Et désolée pour le temps de réponse. Comme ça ne va pas aller en diminuant, du coup, @bacelar, quand je t'écrivais, je te laisse voir, en fait, c'est vraiment à toi de voir. ++

[ludoiphone]

merci , ok !

donc les lignes 4 et 5 servent as creer un thread et une tempo.

donc j'ai reussi a faire avec un QTimer de qt , mais je suis obliger de passer par une nouvelle fonction pour lancer l'objet pac .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
void test()
{
    PAC pac;
    pac.run_pac();
}
 
int main(int argc, char *argv[]) 
{
    QApplication app(argc, argv);
    QApplication::setOverrideCursor(QCursor(Qt::BlankCursor)); // cache pointeur Sourie
 
    MainWindow window;
 
    Consignes *initConsignes;
 
    initConsignes = new Consignes(QString("settings/consignes.ini"), QSettings::IniFormat);
    initConsignes ->controleConsignes();
 
    QTimer timer_modePac;
    int timerPac {1000};
    QObject::connect(&timer_modePac, &QTimer::timeout, test);
    timer_modePac.start(timerPac);
 
    return app.exec();
}

comment faire pour allez directement a la fonction de la class PAC sans crée une autre fonction ??

[bacelar]

donc les lignes 4 et 5 servent as creer un thread et une tempo.

Absolument pas.
La ligne 4 ne fait que suspendre le thread courant (le principal, this de "this_thread") pendant 1 seconde.
La ligne 5 ne fait que lancer la fonction run_pac de l'objet pac.
S'il y a une boucle dans cette fonction, bin, vous bouclez, avant même de lancer la bibliothèque Qt.

Vous ne semblez pas avoir mis à jour vos GitHub, on ne sait pas si vous avez persisté avec vos boucles dans PAC.

J'ai l'impression que vous créez un objet PAC toute les secondes au lieu de garder le même tout le long du programme.
Avec un PAC qui reste tout le long du programme vous pouvez gérer un "historique".
Si vous pouvez reconstruire toutes les informations du PAC de zéro toutes les secondes, pourquoi pas générer un PAC à chaque fois (toute les secondes), mais je suis pas sûr que c'est le cas.
Peut-être faire de la variable pas de la fonction "test" une variable statique pour n'en créer qu'une.

comment faire pour allez directement a la fonction de la class PAC sans crée une autre fonction ??

C'est vraisemblablement une limitation des Timer de Qt qui ne peuvent vraisemblablement pas exécuter de fonction non statique ou libre.
Mais je vous déconseille de modifier la signature/nature de votre fonction "run_pac".
"run_pac" fait partie de la couche business/métier de votre application.
C'est à la partie IHM de s'adapter à la couche métier.
Donc, s'il faut passer par une fonction "spéciale" pour que la couche IHM puisse faire le "hearth beat" des objets métiers, tant mieux.
Avec une autre bibliothèque graphique, vous aurez d'autres contraintes et vous ne voudrez pas changer votre code métier pour chacune des centaines de librairies graphiques qui existent.

Après vérification :
https://doc.qt.io/qt-6/qtimer.html
Vous pouvez très bien lancer une fonction non statique depuis un timer Qt.

[ludoiphone]

salut ,

donc j'ai mis a jour mon github;

oui j'avait remarque que je créait un objet pac toute les secondes , dans la fonction test de mon exemple plus haut , sans "PAC pac;" cela ne compile pas car elle n'est pas declarer.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
PAC pac;
 
void startPac() {
    pac.run_pac();
};
 
int main(int argc, char *argv[]) 
{
    QApplication app(argc, argv);
    QApplication::setOverrideCursor(QCursor(Qt::BlankCursor)); // cache pointeur Sourie
 
    MainWindow window;
 
    Consignes *initConsignes;
 
    initConsignes = new Consignes(QString("settings/consignes.ini"), QSettings::IniFormat);
    initConsignes ->controleConsignes();
 
    QTimer timerPac;
    int timePac {1000};
    QObject::connect(&timerPac, &QTimer::timeout, startPac);
    timerPac.start(timePac);
 
    return app.exec();
}

la je vais etre en vacances donc je vais avoir plus de temp pour me pencher dessu.

[bacelar]

donc j'ai mis a jour mon github;

Cool !!!

oui j'avait remarque que je créait un objet pac toute les secondes , dans la fonction test de mon exemple plus haut

Je ne sais pas si tu t'en es rendu compte à l'écriture du code ou au moment des tests.
Si tu t'en es rendu compte au moment de l'écriture mais que t'étais un peu perdu avec les messages d'erreur du compilateur, c'est "cool", faut juste apprendre à décortiquer les messages d'erreur du compilateur.
Si c'est au moment des tests, c'est que tu manque encore des bases du C++ et qu'il faut encore un peu les potasser pour distinguer les différents types de variable.

sans "PAC pac;" cela ne compile pas car elle n'est pas declarer.

Oui, mais le compilateur est ton ami, il te dit ce qu'y ne va pas, mais pas forcément de manière très explicite, malheureusement.
Il faut prendre le temps de comprendre les messages d'erreurs.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
PAC pac;
 
void startPac() {
    pac.run_pac();
};
...

Ok, utilisation d'une variable globale, pas forcément très recommandé en C++.
Cela fait que s'il y a une modification dans la variable globale, on ne sait pas dans quelle partie du code la modification du code. Et une collision de noms dans les noms des variables globales est si vite arrivée.
Et comme votre objet global a une initialisation "complexe", vous vous exposez très certainement à ce qu'on appelle le "fiasco de l'initialisation des variables globales".

Une approche plus "safe", c'est l'utilisation d'une variable statique "de fonction" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
void startPac() {
    static PAC pac;
    pac.run_pac();
};

Ironiquement, vous avez un exemple parfait d'utilisation des timers dans votre propre code, dans le constructeur de votre classe MainWindow :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
    timerTemperatures = new QTimer(this);
    timerTemperatures ->start(timerTemps);
    connect(timerTemperatures, &QTimer::timeout, this, &MainWindow::affichageTemperatures); // mise a jour de la temperature toute les 10 secondes

(J'apprécie moyennement que ce code lance "timerTemperatures" avant le connect.)
Peut-être que vous utilisez un designer pour créer/maintenir le constructeur de la classe MainWindow, mais, généralement, ils (les designers) ont tendance à générer du code "bourrin" mais fiable.
Ce code montre comment appeler une fonction "non statique/membre" d'un objet d'un type de classe donné.

Mais que cela soit avec votre variable globale, une variable statique, ou un timer configuré "aux petits oignons", vous avez bien réussi à exécuter régulièrement une partie du code de la couche business/métier sans avoir de dépendance avec la technologie de la couche d'IHM.
Donc, si vous changez d'IHM, vous n'aurez pas à changer le code de votre couche business/métier.

Pensez à bien isoler vos classes et énumération dans des fichiers distinctes.
Et pour être encore plus "rigoureux", vous devriez mettre des fichiers des différentes couches (Data, Business/Métier, IHM) dans des sous-répertoires distincts, pour ne pas tout mélanger.

Et votre code est de temps en temps assez mal indenté, pensez à utiliser l'indentation automatique des IDE "modernes" pour vous simplifier cette tâche.

[ludoiphone]

merci , oui j'avais fait plusieurs timer , mais je pensait qu'il fallait absolument etre sur Q_OBJECT.

je m'aperçois d'une chose est que pour la partie IHM , elle devient lente , et sais due je pense au qtimer de mainwindow qui lit mes sondes toute les 10 secondes .

je pense que des Qthread serais le mieux ? j'en avais deja utiliser et je trouvais plus fuide .

en faite j'écrivais les temperatures lue par les sondes sur un fichier toute les 10secondes et puis je lisait le fichier tous les 1Osecondes pour mettre a jour l'affichage des 5 temperatures.
est ce une bonne idée?

[bacelar]

merci , oui j'avais fait plusieurs timer , mais je pensait qu'il fallait absolument etre sur Q_OBJECT.

Vous avez raison, pour la version "de luxe", il faut un QObject.

Dans ce cas, et ne pas ramener une dépendance à Qt dans le code métier, il suffit de créer une classe de "Wrapping" autour de la classe "PAC" du métier dans la couche IHM : PacView par exemple.
Que la couche d'IHM dépende de la couche métier, c'est pas très "grave". (Utile uniquement pour des architecture "hautement' modulaires)
Vous mettrez dans cette classe tout le code nécessaire à Qt pour faire tourner un objet PAC dans Qt.
Votre classe PAC pourra ainsi facilement migrer vers d'autres framework, si nécessaire.
Il suffit que la classe PacView est un membre privé de type PAC, qu'il dérive de QObject et vous faite en sorte de propager les appels réguliers du timer Qt vers l'instance PAC membre de l'objet PacView.
Ainsi, vous avez tous les avantages des fonctionnalités de Qt sans saloper votre code métier, et cela en quelques lignes de code.
Et si Qt nécessite encore des choses qui impacterait négativement votre classe PAC, vous utilisez la classe PacView comme "tampon".
PacView est la classe d'IHM homologue à la classe PAC de la couche métier.
Il sera peut-être pertinent de faire un modèle objet plus spécifique à la couche IHM plus tard, mais pour commencer, ça fait le taf (conception par prototypage à la "SpaceX").

et sais due je pense au qtimer de mainwindow qui lit mes sondes toute les 10 secondes .

Je serais très étonné que cela vienne des QTimer de Qt, bibliothèque extrêmement éprouvée avec des décennies d'expérience.
Je penche plus vers le code appelé par ces timers.
Renseignez-vous sur la disponibilité d'un outil type "profiler" sur votre plateforme cible pour savoir concrètement où passe la puissance CPU.

je pense que des Qthread serais le mieux ? j'en avais deja utiliser et je trouvais plus fuide .

Attention, Qthread vient avec Qt, donc à n'utiliser que dans la couche IHM.
Si vous avez besoin de threads dans la couche métier ou Data, préférez des threads plus "standard".
L'avantage potentiel des Qthread c'est de "mieux" fonctionner avec du code Qt (classes et modèles architecturaux).
Sur des architectures multicœur, l'utilisation de thread améliore intrinsèquement les performances, mais il faut faire cela "intelligemment".
Si la lecture des températures, par exemple, prend du temps et bloque le thread appelant, vous pouvez avantageusement utiliser des threads annexes pour ne pas bloquer l'IHM de manière intempestive.
Mais vous devrez gérer le caractère asynchrone de la disponibilité de ces informations de température.

en faite j'écrivais les temperatures lue par les sondes sur un fichier toute les 10secondes et puis je lisait le fichier tous les 1Osecondes pour mettre a jour l'affichage des 5 temperatures.
est ce une bonne idée?

Je suis de la très très vielle école où les performances des HDD (pas les SDD) rendaient toute lecture/écriture sur disque un gouffre à performance.
Donc, dans l'absolu, je serais moyen chaud.
Mais dans votre domaine, où la sécurité est primordiale, l'utilisation de support "permanant" est très pratique pour les tests, les audits, les analyses, et les validations de sécurité, entre autres.
Mais faites en sorte que cela ne soit pas dans le chemin critique en termes de réactivité de votre engin.

[ludoiphone]

en faite quand je supprime le QTimer de main, l'IHM est plus rapide mais ce bloque pendant la lecture du fichier des sondes via le qtimer de mainwindow.

donc effectivement c'est le code des DS18B20 qui bloque et le Qtimer de main .

et vue que les 2 qtimer lisent les sondes a peut pret en meme temps ca bloque .

[ludoiphone]

j'ai trouver une nouvelle class pour mes sondes , que j'ai poster dans github.
et modifier mon Main .

je pense qu'il faudrais que je face un thread que pour la lecture des sondes en meme temps ecrire les relever dans le fichier "temperatures"

puis lire ce fichier avec des mutex pour eviter l'ecriture et la lecture en meme temp??
mais vue que je vais le lire pour pac et mainwindow j'ai peur que ca creer des conflits .

[bacelar]

en faite quand je supprime le QTimer de main, l'IHM est plus rapide mais ce bloque pendant la lecture du fichier des sondes via le qtimer de mainwindow.

Quand vous parler de "fichier des sondes", vous parlez de "/sys/bus/w1/devices/..." ?
Alors, c'est plus un accès à la sonde via la lingua franca "UNIX" : 'Tout n'est que fichier à accès caractère par caractère' qu'un "vrai" fichier.

Donc, si cet accès n'est pas rapide, le fait de supprimer des attentes en "supprimant le QTimer de main", c'est logique.
Mais vous ne devriez pas avoir 2 parties de code qui interrogent les sondes, mais une seule.
Votre classe MainWindow interroge directement les sondes. Pourquoi ?
En faisant cela, vous bloquez votre IHM pendant les lectures des sondes.

Si on cherche à architecture le projet, vous devriez avoir une couche IHM qui interroge une couche métier, qui elle-même interroge une couche hardware.
Un avantage évident de ce découpage, c'est de pouvoir changer de couche d'IHM sans tout refaire.
Mais c'est aussi de ne pas avoir des contraintes comme de l'affichage dans des process "temps réels", comme ne pas attendre un affichage pour réagir à quelque chose, etc...

Avec votre classe MainWindow, votre IHM interroge directement le hardware, avec tout ce que cela engendre comme désagrément : quid du process s'il est iconifié, etc...
Votre classe MainWindow devrait interroger votre couche métier : votre classe PAC actuellement.
Ainsi, vous n'aurez pas à gérer de la contention d'accès sur les sondes.
Votre classe MainWindow afficherait les températures fournit par l'objet PAC, par directement interroger les sondes.

donc effectivement c'est le code des DS18B20 qui bloque et le Qtimer de main .

Cela bloque à la fois PAC et MainWindow. MainWindow devrait utiliser PAC pour ne pas avoir à repayer le temps d'accès aux sondes.
PAC pourrait utiliser des thread annexes, non graphique, pour faire la récolte des données des sondes.

et vue que les 2 qtimer lisent les sondes a peut pret en meme temps ca bloque .

Problème résolu si MainWindow n'interroge pas les sondes.

j'ai trouver une nouvelle class pour mes sondes , que j'ai poster dans github.
et modifier mon Main .

Nouvelle classe, oui mais qui utilise toujours le même canal d'accès au hardware, donc toujours les mêmes limitations.
Et la "nouvelle" classe utilise des "#define" à la C des années 700 plutôt que des "const string" ou des "const std::path" plus "C++esque".
Pas de validation de type avec ces MACRO du précédent millénaire.
La qualité du code de la nouvelle classe est pas terrible. (MACRO, fonction de conversion °C °F non statique, etc...)

je pense qu'il faudrais que je face un thread que pour la lecture des sondes en meme temps ecrire les relever dans le fichier "temperatures"

Pourquoi écrire dans un fichier et pas simplement stocker ces données dans l'objet PAC ?
Vous pourrez utiliser des primitives de synchronisation multithread dans la classe PAC et les problèmes de contention sur ces valeurs sera réglé.

puis lire ce fichier avec des mutex pour eviter l'ecriture et la lecture en meme temp??
mais vue que je vais le lire pour pac et mainwindow j'ai peur que ca creer des conflits .

cf. le début de ce message : en utilisant correctement la séparation en couche, ces problèmes disparaissent d'eux-mêmes.

[ludoiphone]

"/sys/bus/w1/devices/..." ? oui c'est bien cela.

Votre classe MainWindow interroge directement les sondes. Pourquoi ? - pour mettre a jour l'affichage des 5 temperatures.

Pourquoi écrire dans un fichier et pas simplement stocker ces données dans l'objet PAC ? peur de prendre trop memoire .

Vous pourrez utiliser des primitives de synchronisation multithread dans la classe PAC et les problèmes de contention sur ces valeurs sera réglé. avez vous un exemple ? merci

[bacelar]

Votre classe MainWindow interroge directement les sondes. Pourquoi ? - pour mettre a jour l'affichage des 5 temperatures.

Pourquoi votre IHM doit avoir accès directement au hardware ?
Elle devrait demander les températures à un élément de la couche métier, comme PAC, par exemple.
Ainsi, votre IHM n'est pas dépendante des particularités du hardware et ne freeze pas pour "rien".

Si votre PAC à besoin des températures toutes les secondes, elle le fera avec ces propres threads, sans freezer l'IHM.

Pourquoi écrire dans un fichier et pas simplement stocker ces données dans l'objet PAC ? peur de prendre trop memoire .

Je comprends pas la logique de votre raisonnement.
Vous avez justes des nombres qui se mettent à jours en mémoire et pas des buffers d'entrée/sorti sur fichier.
Pour le fonctionnement de votre IHM, vous avez déjà ces nombres.
C'est l'usage de fichier qui est bien plus encombrant en mémoire que de simples nombres.

Vous pourrez utiliser des primitives de synchronisation multithread dans la classe PAC et les problèmes de contention sur ces valeurs sera réglé. avez vous un exemple ? merci

Je crois que vous avez déjà posté du code truffé de mutex, bin c'est juste ça, à faire plus "intelligemment".

Essayez de "muscler" un peu vos connaissances en C++, pour pouvoir sélectionner du code en fonction de ses "qualités". Car les classes DS18B20 successives ne sont pas "terrible".

[ludoiphone]

Pourquoi votre IHM doit avoir accès directement au hardware ? non pas forcement .

"Il suffit que la classe PacView est un membre privé de type PAC, qu'il dérive de QObject et vous faite en sorte de propager les appels réguliers du timer Qt vers l'instance PAC membre de l'objet PacView."

je vais faire avec votre proposition , car pas trop le choix en fonction de Q_OBJECT pour éviter de pourrir mon code PAC.

comme cela je pourrais utiliser les signales, les slots , les qtimers et les Qthreads.

pour les ds18B20 j'ai fouiner un peut partous, et malheureusement je touve pas grand chose sauf pour pithon.
peut-etre avez vous une idée pour fabriquer un truc propre .?

je m'attendait pas a autant de complexitude .

le probleme est qu'il faudras bien un timer pour pac pour mettre a jours les temperature des sondes
et pour verifier mon thermostat.

je suppose que je devrais lancer l'ihm via PacView dans un qthread?

[bacelar]

je m'attendait pas a autant de complexitude .

Attention, on peut faire beaucoup plus simple, comme votre code initial, où tout était mélangé.
Mais vous allez très vite arriver à des impasses.
Comme le fait que votre IHM soit souvent freezée mais aussi que vos traitements en arrière-plan soient freezés par votre IHM, car vous n'aurez qu'un thread pour les 2.

La complexité, c'est un dosage.
Il faut qu'elle soit adaptée au but recherché.
Mais avec un peu d'expérience, le découpage en couche devient "instinctif" et devient plus une simplification qu'une complexification.

Vous pouvez toujours tenter la version bourrin simple, mais vous aller rapidement être limité.
Et si vous continuez, vous allez bien plus vite complexifier le machin parce que vous serez partie d'une base simple mais bancale.

J'espère que l'architecture que je propose reste assez simple mais bien plus flexible que l'approche "bourrin".
Juste avec un peu de méthode et de précaution, on devrait pouvoir implémenter FACILEMENT des choses "évolués" comme l'asynchronisme entre l'IHM et le hardware, la modularité, l'évolutivité, etc...

Vous pouvez toujours tenter l'approche bourrin comme un POC (Prof of Concept), mais vous serez très certainement obligé de tout refaire pour ajouter une fonctionnalité "non trivial".

Pourquoi votre IHM doit avoir accès directement au hardware ? non pas forcement .

Alors, je vous conseille de faire simple : gérer les choses avec des niveaux d'abstractions différents => couches logicielles :
- Data/Hardware
- Métier (implémentation de la logique interne de l'application)
- IHM (qui fait que de l'affichage)

Donc supprimez toute référence directe au sonde "hardware" et passez par la couche métier (l'objet de type PAC), pour ne pas avoir à gérer au niveau de l'IHM la latence des sondes "physiques".

pour les ds18B20 j'ai fouiner un peut partous, et malheureusement je touve pas grand chose sauf pour pithon.
peut-etre avez vous une idée pour fabriquer un truc propre .?

https://raspberrypi.stackexchange.co...nsors-with-c-c
Ça sent le machin un peu bordélique tout ça, entre les API spécifiques GPIO et les paradigmes "Unixiens".
Si vous suivez mon conseil de faire votre truc en couches, choisissez l'un de ces machins comme base pour votre couche hardware, mais faites en sorte de facilement pouvoir changer de "techno hardware" sans avoir à changer le reste de votre application.

Même la référence donnée : https://github.com/sd1024/ds18b20, le code n'est vraiment pas terrible (ne fonctionne "correctement" que dans une console, archaïsmes du C comme des #define, etc...), mais est bien plus riche que les 2 "modules" que vous avez mis successivement dans votre GitHub.
Je ne sais pas si tous ces "mauvais" codes sont lié aux limitations des chaines de compilations sur la plateforme cible ou si c'est lié au (très) niveau moyen des programmeurs C++, ou à l'âge moyen du code, sur la plateforme.
Mais la quantité totale des fonctionnalités de ces trucs est telle qu'il très envisageable que vous puissiez faire la même chose de 0 et avec des bases plus saine/ plus à jour.

Peut-être que la qualité du code Python sur cette plateforme est meilleure qu'en C++, alors inspirez-vous de ces codes pour faire le vôtre, s'ils n'utilisent pas les spécificités de Python non facilement transposable en C++ (type dynamique, etc...).
Pour la programmation "système", le Python ne sert que de coquille à des fonctionnalités créées en C.
Dans ce cas, vous pourrez directement utiliser ces fonctionnalité C depuis votre code C++.

Donc, en résumé, prenez l'un de ces bidules qui marchouille mais qui offre les services dont vous avez besoin, foutez-le de telle manière que vous pouvez facilement en changer. Vous le corrigerez à votre sauce plus tard, en espérant que le code initial n'est pas trop bogué.
Mais, pour l'instant, ceux à votre disposition ne devraient pas être utilisés dans le thread d'IHM (à vérifier avec les résultats du profiler).

Mais tout ça, c'est juste un peu de gymnastique mentale.

le probleme est qu'il faudras bien un timer pour pac pour mettre a jours les temperature des sondes
et pour verifier mon thermostat.

2 approches : soit votre couche métier/pac est autonome d'un point de vue timer (=> threads internes à la couche), soit fournit indirectement via le code "appelant" (=> approche type PacView).
Pour la première approche, PAC contient un std:::thread qu'on démarre dans le constructeur et qu'on arrête dans le destructeur.
Pour la seconde, le timer est fourni par "l'extérieur".
Dans la première approche, il faut synchroniser les accès aux données partagées entre les différents threads.
Dans la seconde, on fait l'assertion que le code externe gère cela lui-même ( dans le cas PacView, il n'y a qu'un thread).
Vous pouvez toujours mettre les synchronisations d'accès dans le cas 2, mais elles seront inutiles (mais ça peut être pratique si on change d'approche en cours de développement).

Attention, PAC "ne met pas a jours" l'affichage des températures mais ne fait que stocker la dernière température lue.
C'est quoi "vérifier" le thermostat ???

je suppose que je devrais lancer l'ihm via PacView dans un qthread?

Non, l'avantage de PacView, c'est de tout faire dans un thread, celui de l'affichage => pas de nécessité de synchronisation d'accès aux données partagées.
L'IHM, c'est votre classe MainWindow, rien d'autre.
Si elle à besoin d'une PacView pour fonctionner, il suffit d'ajouter un objet PacView pour fonctionner. Pourquoi ne pas ajouter un objet PacView comme champ de la classe "MainWindow" ?