[Jeedom V3.1] Problèmes avec la mise à jour

[Bosquetia]

Hello,

Je te conseille d'aller relire le premier post de ce topic.
Tu verras que tu n'as pas la dernière version...

[Fifirept]

Salut à tous,

A mon tour de venir grossir les rangs de ceux qui rencontrent des soucis sans trouver de solution.
Je suis sur RASPBerry "Jessie".
Depuis la mise à jour 3.1.3, 3.1.4, 3.1.5 ,sur le plugin "Caméra", le téléchargement d'une ou plusieurs vidéos (bouton "Télécharger") m'envoi vers une page vide avec une popup d'erreur de connexion.
J'ai tenté la même opération avec plusieurs navigateurs (Edge, Chrome, Firefox, Opera), même résultat.
J'ai tenté de consulter le message d'erreur dans les logs mais rien n’apparaît.
Dernier diag, en tentant de suivre le chemin dans debian, il semble qu'il n'existe pas.
Quelqu'un d'autre rencontre ce problème?

EDIT: Je viens de constater que l'URL appelée par le bouton "Télécharger" contient des "%2F" à la place des "/"
192.168.1.150/core/php/downloadFile.php/pathfile=%2Fvar%2Fwww%2Fhtml%2Fcore%2Fphp%2F..%2F..%2Fplugins%2Fcamera%2Fdata%2Frecords%2F51%2FCam-int.-1_2017-09-29_18-34-59.mp4

Malgré les différentes mises à jour du plugin "Caméra", mon problème est toujours là.
Toujours personne pour une idée?
Dois-je cross poster dans la section Plugin Caméra?

[Didou91210]

Hello,
Je resume ma mise à jour par : "500 : Internal Server Error"

Et pourtant tout semblait bien parti. J'avais attendu 2-3 jours, histoire de pas me planter comme à la dernière mise à jour !
Tout semblait bien engagé avec un trentaine de plugin à mettre à jour une fois le passage le core passé correctement en 3.1.5
Les passages sont OK sauf un : l'update du caldav mais pas important !

Le changement semblait donc presque transparent hormis les camera toutes les 3 en OFF ! J'intervient sur le plugin Camera en configuration. Un arrêt-relance et bing ! ce fameux message qui apparait à chaque lancement d'un processus, d'un scenario etc... Impossibilité de passer en configuration, d'accéder aux sauvegardes etc... Heureusement j'ai sorti de Jeedom une save avant changement de version mais je n'ai pas envie de repartir de zero et refaire une SD comme la fois dernière !

Que faire ? j'ai essayé sur plusieurs navigateurs différents et pareil, erreur 500 : Internal Server Error
merci pour votre aide

[m.georgein]

Je ne rencontre pas ce problème
Vérifier si la valeur de l'équipement est historisée

Oui bien sur, c'est historisé, et j'ai testé sur plusieurs équipements et deux installation différentes (DIY sur NUC), j'ai testé quelques autres fonctions statistiques, apparemment les problèmes ne concerne que ces deux fonctions ...

Bonjour,

Je rencontre le même problème depuis le passage en V3.xx mais je n'y ai pas fais attention tout de suite.
Je suis actuellement sur pi 2 en V3.1.5 et j'utilise un scenario pour éteindre des éclairages selon différents critères, parmi lesquels la non détection de présence depuis un certain temps.
Le scenario fait donc appel à la fonction lastChangeStateDuration pour éteindre si non présence depuis > 900 secs.
Depuis le passage en V3.xx (je ne suis pas certains que ce soit depuis la première V3), l'éclairage s'éteint et se rallume sans arrêt.
Je suis donc allé voir dans les logs et la valeur renvoyée par lastChangeStateDuration est du genre "1506932411" (ce n'est pas toujours la même, mais ça commence toujours par "15069"). Du coup comme c'est supérieur à 900, le scénario éteint la lumière puis va la rallumer à la prochaine détection de mouvement, ainsi de suite.
Ce scénario n'est pas nouveau et fonctionnait correctement en 2.x.
La valeur de présence testée est bien historisée.

D'autres personnes ont elles rencontrées ce problème ?


En fait il semble y avoir un problème d'heures dans les historiques, du moins celui de certains objets.
Je suis allé voir celui de mon détecteur de présence et il est en avance sur l'heure actuelle:


J'ai fait cette capture à 15h38 aujourd'hui et il y a des évènements jusqu'à 17h30....

Des idées ??

La valeur 1506932411 correspond au TimeStamp de unix.

Effectivement les fonctions lastChangeStateDuration, stateDuration et autres "State" ne fonctionne plus et renvoie ou le timestamp unix ou -1 (pas d'historique)
Exemple

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression stateDuration(#[Salon][Salon][S_On_Off]#, 1) == -1
Résultat en 3.0.11 : 11976 - résultat en 3.1.5 : -1

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression lastChangeStateDuration(#[Salon][Salon][S_On_Off]#, 1) == 1506953016
Résultat en 3.0.11 : 11976 - résultat en 3.1.5 : 1506953016

Pour les fonctions de type "max" ou "min" elle renvoie systématiquement 999.8 ou 1000.24.
Exemples :

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression max(#[Salon][Compteur general][Consommation]#, 1 mois) == 999.8
Résultat en 3.0.11 : 2277.7 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression maxBetween(#[Salon][Compteur general][Consommation]#, 2017-08-01 00:00:00, 2017-08-31 23:59:59) == 999.8
Résultat en 3.0.11 : 1443.7 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression statistics(#[Salon][Compteur general][Consommation]#, max, 1 mois) == 999.8
Résultat en 3.0.11 : 2277.86 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression statisticsBetween(#[Salon][Compteur general][Consommation]#, max, 2017-08-01 00:00:00, 2017-08-31 23:59:59) == 999.8
Résultat en 3.0.11 : 1443.74 - résultat en 3.1.5 : 999.8

Donc TOUTES les fonctions de type "min" donne comme résultat 999.8, par contre les fonctions de type "min" renvoie 1000.24 systématiquement.

Pour les fonctions de type "state" on peut s'en sortir en les appelant directement depuis la classe history ou scenarioExpression, par contre pour les fonctions de type min/max je n'ai pas trouvé de détournement.

[eXo33]

Bonjour à tous,

Un grand merci aux développeurs et à la communauté active ! Utilisateur de Jeedom depuis un bout de temps, il donne entière satisfaction à toute la famille, et son arrêt pour maintenance est toujours remarqué !

Je vous raconte ma petite histoire :

Je suis actuellement en 2.4.6 (installé sur un NUC avec une Debian Jessie à jour)

J'ai les plugins suivants (pas de score >5 si j'ai bien regardé):
Protocole domotique : RFXcom, Z-Wave
Communication : App Mobile, Artyom (désactivé), AutoRemote, Mail, Network, PushBullet, Rss, SMS (désactivé)
Objets communicants : Dash Button, Orvibo
Monitoring : Monitoring, SNMP
Multimédia : DL Control, Kodi, Samsung TV, SqueezeBox Control
Organisation : Agenda, DomoGeek, Informations du Jour, Mode
Programmation : Click link, Virtuel, Widget
Sécurité : Alarme, Caméra
Déplacement : Geoloc
Météo : Forecast.io, Héliotrope, Netatmo Station, Prévision pluie à 1H
Bien-être : Thermostat

J'ai tenté de mettre à jour hier, un peu à l'arrache et sans lire les 23 pages ici présentes. Résultat : ça a bugué !
Bon, j'ai analysé le problème, et je n'avais pas assez de place dans le /var (problème récurrent sur mon install que je n'avais pas vraiment traité)
C'est maintenant fait à grands coups de Gparted (j'avais de la place sur le SSD)

J'ai retenté une mise à jour (toujours sans avoir lu les 23 pages), et là j'ai obtenu un menu principal avec tous les titres entourés par des doubles accolades {{ XXX }}, menus "fonctionnels" dans le sens ou je pouvais voir ce qu'il y avait dedans, mais toutes les pages que je tentais de charger restaient désespérément vides. Le menu en haut à droite (admin, déconnexion,...) était remplacé par une erreur SQL (un truc du genre 20S40, mais j'ai pas noté, désolé).

J'ai donc restaurer l'image complète de ma Jeedom/Debian 2.4.6 et j'ai lu les 23 pages entre hier soir et ce matin.
A la lumière des posts, j'ai :
- repassé le thème en "Default"
- activé tous les logs en niveau warning

Je voulais simplement vous demander :
A) Quels autres précautions je pouvais prendre avant de lancer la MàJ
B) Y'a-t-il une procédure particulière quand on a autant de retard (2.4.6 > 3.1.5).

Merci d'avance pour votre aide

EDITs : voici la page santé en 2.4.6

[batmobyl]

Salut à tous,

j'ai lu les 23 pages de ce topic, et fais aussi une recherche dans le forum concernant mon problème, sans succès.

Contexte : Je suis en DYI avec RPi3 + SD sous Debian Jessie

La dernière mise à jour Core faite y'a 2 jours s'est hyper bien passée. J'ai même lancé une sauvegarde après la maj tellement tout j'étais fier
Par contre, un plugin ne voulait pas se mettre à jour (Telegram), alors j'ai d'abord seulement tenté un petit reboot du RPi.

Et là, au redémarrage... c'est le drame :




Sous Chrome et Firefox, en interne ou en externe, le même résultat :
{"metazoneInfo":{"Africa":{"bidjin":[{"mzone":"GMT"}],"Accrc":[{"mzone":"GMT"}],.... blablabla.

J'ai toujours accès en ssh à mon RPi, alors avant de rechercher dans le forum comment faire une restauration en ssh, je voulais savoir si y'avait pas autre chose à tenter

Mille merci de votre aide.

[Theduck38]

Hello @eXo33,

Je te donne ma checklist que j'avais construite pour passer de 2.4 vers 3.0 au fur et à mesure des lectures de posts de la version 3 :

- MàJ plugins qui peuvent l'être
- Régler le /tmp à + de RAM (512 Mo)
- Vider le cache
- Voir pour vider le dossier /temp
- Reboot
(- Désactivation de tous les plugins) => finalement pas fait
- MàJ Core
- Sauvegarde et transfert sauvegarde
- MàJ Core plusieurs fois si nécessaire
- Désactivation des traductions auto
- Reboot
- Sauvegarde et transfert sauvegarde
- (Activation des plugins 1 par 1) et mise à jour des plugins
- Mettre à jour le Framework SC et modifier les scénarios
- Pb sur plugins ( https://www.jeedom.com/market/index.php?v=d&p=scoring )
- Si la roue tourne indéfiniment sur l'écran des plugins : disable ipv6
viewtopic.php?f=23&t=27474&p=512928&sid ... 3c#p512928

[fwehrle]

Oui bien sur, c'est historisé, et j'ai testé sur plusieurs équipements et deux installation différentes (DIY sur NUC), j'ai testé quelques autres fonctions statistiques, apparemment les problèmes ne concerne que ces deux fonctions ...

Bonjour,

Je rencontre le même problème depuis le passage en V3.xx mais je n'y ai pas fais attention tout de suite.
Je suis actuellement sur pi 2 en V3.1.5 et j'utilise un scenario pour éteindre des éclairages selon différents critères, parmi lesquels la non détection de présence depuis un certain temps.
Le scenario fait donc appel à la fonction lastChangeStateDuration pour éteindre si non présence depuis > 900 secs.
Depuis le passage en V3.xx (je ne suis pas certains que ce soit depuis la première V3), l'éclairage s'éteint et se rallume sans arrêt.
Je suis donc allé voir dans les logs et la valeur renvoyée par lastChangeStateDuration est du genre "1506932411" (ce n'est pas toujours la même, mais ça commence toujours par "15069"). Du coup comme c'est supérieur à 900, le scénario éteint la lumière puis va la rallumer à la prochaine détection de mouvement, ainsi de suite.
Ce scénario n'est pas nouveau et fonctionnait correctement en 2.x.
La valeur de présence testée est bien historisée.

D'autres personnes ont elles rencontrées ce problème ?


En fait il semble y avoir un problème d'heures dans les historiques, du moins celui de certains objets.
Je suis allé voir celui de mon détecteur de présence et il est en avance sur l'heure actuelle:


J'ai fait cette capture à 15h38 aujourd'hui et il y a des évènements jusqu'à 17h30....

Des idées ??

La valeur 1506932411 correspond au TimeStamp de unix.

Effectivement les fonctions lastChangeStateDuration, stateDuration et autres "State" ne fonctionne plus et renvoie ou le timestamp unix ou -1 (pas d'historique)
Exemple

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression stateDuration(#[Salon][Salon][S_On_Off]#, 1) == -1
Résultat en 3.0.11 : 11976 - résultat en 3.1.5 : -1

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression lastChangeStateDuration(#[Salon][Salon][S_On_Off]#, 1) == 1506953016
Résultat en 3.0.11 : 11976 - résultat en 3.1.5 : 1506953016

Pour les fonctions de type "max" ou "min" elle renvoie systématiquement 999.8 ou 1000.24.
Exemples :

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression max(#[Salon][Compteur general][Consommation]#, 1 mois) == 999.8
Résultat en 3.0.11 : 2277.7 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression maxBetween(#[Salon][Compteur general][Consommation]#, 2017-08-01 00:00:00, 2017-08-31 23:59:59) == 999.8
Résultat en 3.0.11 : 1443.7 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression statistics(#[Salon][Compteur general][Consommation]#, max, 1 mois) == 999.8
Résultat en 3.0.11 : 2277.86 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression statisticsBetween(#[Salon][Compteur general][Consommation]#, max, 2017-08-01 00:00:00, 2017-08-31 23:59:59) == 999.8
Résultat en 3.0.11 : 1443.74 - résultat en 3.1.5 : 999.8

Donc TOUTES les fonctions de type "min" donne comme résultat 999.8, par contre les fonctions de type "min" renvoie 1000.24 systématiquement.

Pour les fonctions de type "state" on peut s'en sortir en les appelant directement depuis la classe history ou scenarioExpression, par contre pour les fonctions de type min/max je n'ai pas trouvé de détournement.

Je viens de faire un test rapide avec min et max, et j'ai un max de ma conso d'eau par mois qui est toujours égal à 10..
Et sur une autre valeurs, il est à 100.
Sans qu'aucune de ces 2 valeurs ne veuille dire qqch...

[eXo33]

Hello @eXo33,

Je te donne ma checklist que j'avais construite pour passer de 2.4 vers 3.0 au fur et à mesure des lectures de posts de la version 3 :

- MàJ plugins qui peuvent l'être
- Régler le /tmp à + de RAM (512 Mo)
- Vider le cache
- Voir pour vider le dossier /temp
- Reboot
(- Désactivation de tous les plugins) => finalement pas fait
- MàJ Core
- Sauvegarde et transfert sauvegarde
- MàJ Core plusieurs fois si nécessaire
- Désactivation des traductions auto
- Reboot
- Sauvegarde et transfert sauvegarde
- (Activation des plugins 1 par 1) et mise à jour des plugins
- Mettre à jour le Framework SC et modifier les scénarios
- Pb sur plugins ( https://www.jeedom.com/market/index.php?v=d&p=scoring )
- Si la roue tourne indéfiniment sur l'écran des plugins : disable ipv6
viewtopic.php?f=23&t=27474&p=512928&sid ... 3c#p512928

Merci pour ton aide @Theduck38

J'ai donc suivi ta checklist (plus ou moins )
> Maj plugins (erreur sur le RFXCOM, j'ai pas insisté), donc au final 5 ou 6 plugins effectivement mis à jour
> Vider le cache
> Reboot
> Maj Core
/!\ il faut attendre - le log disparait mais il se passe des trucs qu'on ne voit pas
les logs reprennent ensuite et se plantent sur la désinstallation de phpsysinfo)
> Maj forcée sur Core (3.1.5 installée apparemment avec succès)
> Maj des plugins
> Maj des dépendances (automatique)
> 4 plugins désactivés (RSS, SNMP, PrevisionPluie et dlControl) : il n'y a que prévisionpluie qui m'embête un peu, c'était pratique d'entendre "Prends ton parapluie". Sinon les autres on s'en passe.

Et au final, Tout est au vert:



Me reste plus qu'à farfouiller et mettre en oeuvre le paramétrage des nouvelles fonctionnalités

encore un GRAND MERCI aux devs et à ceux qui aident (@Theduck38)

[maitrje]

Oui bien sur, c'est historisé, et j'ai testé sur plusieurs équipements et deux installation différentes (DIY sur NUC), j'ai testé quelques autres fonctions statistiques, apparemment les problèmes ne concerne que ces deux fonctions ...

Bonjour,

Je rencontre le même problème depuis le passage en V3.xx mais je n'y ai pas fais attention tout de suite.
Je suis actuellement sur pi 2 en V3.1.5 et j'utilise un scenario pour éteindre des éclairages selon différents critères, parmi lesquels la non détection de présence depuis un certain temps.
Le scenario fait donc appel à la fonction lastChangeStateDuration pour éteindre si non présence depuis > 900 secs.
Depuis le passage en V3.xx (je ne suis pas certains que ce soit depuis la première V3), l'éclairage s'éteint et se rallume sans arrêt.
Je suis donc allé voir dans les logs et la valeur renvoyée par lastChangeStateDuration est du genre "1506932411" (ce n'est pas toujours la même, mais ça commence toujours par "15069"). Du coup comme c'est supérieur à 900, le scénario éteint la lumière puis va la rallumer à la prochaine détection de mouvement, ainsi de suite.
Ce scénario n'est pas nouveau et fonctionnait correctement en 2.x.
La valeur de présence testée est bien historisée.

D'autres personnes ont elles rencontrées ce problème ?


En fait il semble y avoir un problème d'heures dans les historiques, du moins celui de certains objets.
Je suis allé voir celui de mon détecteur de présence et il est en avance sur l'heure actuelle:


J'ai fait cette capture à 15h38 aujourd'hui et il y a des évènements jusqu'à 17h30....

Des idées ??

La valeur 1506932411 correspond au TimeStamp de unix.

Effectivement les fonctions lastChangeStateDuration, stateDuration et autres "State" ne fonctionne plus et renvoie ou le timestamp unix ou -1 (pas d'historique)
Exemple

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression stateDuration(#[Salon][Salon][S_On_Off]#, 1) == -1
Résultat en 3.0.11 : 11976 - résultat en 3.1.5 : -1

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression lastChangeStateDuration(#[Salon][Salon][S_On_Off]#, 1) == 1506953016
Résultat en 3.0.11 : 11976 - résultat en 3.1.5 : 1506953016

Pour les fonctions de type "max" ou "min" elle renvoie systématiquement 999.8 ou 1000.24.
Exemples :

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression max(#[Salon][Compteur general][Consommation]#, 1 mois) == 999.8
Résultat en 3.0.11 : 2277.7 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression maxBetween(#[Salon][Compteur general][Consommation]#, 2017-08-01 00:00:00, 2017-08-31 23:59:59) == 999.8
Résultat en 3.0.11 : 1443.7 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression statistics(#[Salon][Compteur general][Consommation]#, max, 1 mois) == 999.8
Résultat en 3.0.11 : 2277.86 - résultat en 3.1.5 : 999.8

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression statisticsBetween(#[Salon][Compteur general][Consommation]#, max, 2017-08-01 00:00:00, 2017-08-31 23:59:59) == 999.8
Résultat en 3.0.11 : 1443.74 - résultat en 3.1.5 : 999.8

Donc TOUTES les fonctions de type "min" donne comme résultat 999.8, par contre les fonctions de type "min" renvoie 1000.24 systématiquement.

Pour les fonctions de type "state" on peut s'en sortir en les appelant directement depuis la classe history ou scenarioExpression, par contre pour les fonctions de type min/max je n'ai pas trouvé de détournement.

ok, donc on va bidouiller en attendant la correction dans une prochaine version du core.
merci pour l'analyse détaillée.

[fwehrle]

[2017-10-02 16:03:36][SCENARIO] SP getExp : Expression stateDuration(#[Salon][Salon][S_On_Off]#, 1) == -1
Résultat en 3.0.11 : 11976 - résultat en 3.1.5 : -1

Petite précision (mais ne vaudrait-il pas mieux créer un sujet à part pour ce bug, ou le mettre dans le fil de la dispo de la MAJ, car ce n'est pas un problème d'installation de la v3.1.X) :
Le problème n'apparait que si on précise une valeur.
stateDuration(#[Maison][Présence][Etat]#, 1 )>=(10*60) renvoi -1
alors que :
stateDuration(#[Maison][Présence][Etat]# )>=(10*60) fonctionne

Loic, si tu nous lis.

[loic]

Essayes sans l'espace avant le 1

[maitrje]

Essayes sans l'espace avant le 1

Effectivement, sans espace avant le 1 dans lastChangeStateDuration(#[Salon][Motion Sensor][Présence]#,1) c'est tout bon.

Merci Loïc !

[m.georgein]

Essayes sans l'espace avant le 1

ReBonjour,

Effectivement pour les fonctions stateDuration, lastStateDuration, lastChangeStateDuration, min et max il s'agit d'un espace en trop en tête des paramètres $Value ou $_period. Personnellement j'ai rajouté $value = trim($value) dans les class history et scenarioExpression pour les fonctions concernées.
L'astuce de Loïc fonctionne également et à l'avantage de ne pas demandé de bricoler le code !!! La correction ne devrait pas être trop dure à faire


Par contre il reste un problème (inexistant sur la 3.0.11) avec les fonctions minBetween et maxBetween. Là le problème vient apparemment de sql car en effectuant la requête :

Code : Tout sélectionner

SELECT AVG(value) as avg, MIN(value) as min, MAX(value) as max, SUM(value) as sum, COUNT(value) as count, STD(value) as std, VARIANCE(value) as variance 
from (
			SELECT * FROM `history` WHERE `cmd_id` = '4330' AND `datetime` >= '2017-08-15' AND `datetime` <= '2017-08-31'
			UNION ALL
			SELECT * FROM `historyArch` WHERE `cmd_id` = '4330' AND `datetime` >= '2017-08-15' AND `datetime` <= '2017-08-31'
) as dt

si la fourchette de dates est trop longue le résultat est farfelu, là c'est OK si 2017-08-15 mais absurde si 2017-08-01 ....
Je précise que je suis en SQL 5.5.57-0+deb8u1 dans mes deux install de Jeedom (machine clownée).

Y aurait il un paramètre caché quelques part qui limiterait la profondeur d'exploration de la base MySQL ???

Désolé d'avoir encombré ce fil avec ces problèmes mais ils peuvent être déstabilisant pour ceux qui passent en 3.1.5 et ne sont pas trop doué avec les codes !

[loic]

J'ai rajouté une sécurité pour l'espace (a tester je me sers d'aucune de ces fonction).
Pour le 2eme soucis faudrait tester avec le CAST je pense ca doit marcher comme en 3.0

[m.georgein]

J'ai rajouté une sécurité pour l'espace (a tester je me sers d'aucune de ces fonction).
Pour le 2eme soucis faudrait tester avec le CAST je pense ca doit marcher comme en 3.0

Sorry, mais je sais pas ce qu'est le CAST , et google ne m'a pas avancé !!!

[loic]

Ok pas grave je vais voir avec les bêta-testeurs

[fwehrle]

J'ai rajouté une sécurité pour l'espace (a tester je me sers d'aucune de ces fonction).
Pour le 2eme soucis faudrait tester avec le CAST je pense ca doit marcher comme en 3.0

Mon sauveur!
Je me voyais déjà devoir me taper 300 scenarios à la main pour corriger... (parce que moi, je m’en sers depuis le début (2015))
Merci

[Fifirept]

Salut à tous,

A mon tour de venir grossir les rangs de ceux qui rencontrent des soucis sans trouver de solution.
Je suis sur RASPBerry "Jessie".
Depuis la mise à jour 3.1.3, 3.1.4, 3.1.5 ,sur le plugin "Caméra", le téléchargement d'une ou plusieurs vidéos (bouton "Télécharger") m'envoi vers une page vide avec une popup d'erreur de connexion.
J'ai tenté la même opération avec plusieurs navigateurs (Edge, Chrome, Firefox, Opera), même résultat.
J'ai tenté de consulter le message d'erreur dans les logs mais rien n’apparaît.
Dernier diag, en tentant de suivre le chemin dans debian, il semble qu'il n'existe pas.
Quelqu'un d'autre rencontre ce problème?

EDIT: Je viens de constater que l'URL appelée par le bouton "Télécharger" contient des "%2F" à la place des "/"
192.168.1.150/core/php/downloadFile.php/pathfile=%2Fvar%2Fwww%2Fhtml%2Fcore%2Fphp%2F..%2F..%2Fplugins%2Fcamera%2Fdata%2Frecords%2F51%2FCam-int.-1_2017-09-29_18-34-59.mp4

Malgré les différentes mises à jour du plugin "Caméra", mon problème est toujours là.
Toujours personne pour une idée?
Dois-je cross poster dans la section Plugin Caméra?

Toujours personne?

[m.georgein]

J'ai rajouté une sécurité pour l'espace (a tester je me sers d'aucune de ces fonction).
Pour le 2eme soucis faudrait tester avec le CAST je pense ca doit marcher comme en 3.0

Après enquète j'ai retrouvé le CAST
Effectivement en modifiant l'en t^te de la requète de getStatistique de la class statistique de la manière suivante :

Code : Tout sélectionner

		$sql = 'SELECT AVG(value) as avg, MIN(cast(value as decimal(12,2))) as min, MAX(cast(value as decimal(12,2))) as max, SUM(value) as sum, COUNT(value) as count, STD(value) as std, VARIANCE(value) as variance
		FROM (

Tout les chiffres redeviennent OK

Merci Loïc pour tes indications !