Restauration V4 sur RPI3 de Prod

Bonjour,
J’ai installé une V4 sur un RPI3 de test.
Après avoir résolu les PB de Widgets et autres je fait une sauvegarde.
Je restaure cette sauvegarde sur mon RPI3 de prod et tout semble corrects a part que je retrouve pas mes WIDGETS crées avec l’outil WIDGET de la V4.
OU sont ILS ???

Merci

39 Vues aucune réponse. Je dois être le seul.
J’ai ma petite idée mais j’aurais souhaité une réponse d’un pro !!

Cdlt

Salut,

Tu les as fait via le menu code ?

@rombautsdidier
Salut,
Je les ai fait avec le menu Outils,WIDGET.
Certain création simple Info , d’autres Action avec remplacement.

et d’autres…

Et quand tu va dans outil widget y’a rien ?
Ils sont en base donc backupés

@kiboost
Non il n’y a rien.

As-tu utilisé des icônes ou des images? Est-ce qu’en cas d’image, la sauvegarde les prend avec?

Des images pour les WIDGETS info

Tu sais que tu peu faire un seul widget et l’applique sur autant de commandes ou équipements que tu veut. Pas besoin de faire plusieurs fois le même justement

@kiboost
Oui je sais je l’ai fait pour certains.

Ceux que tu vois ce sont en fait des VIRTUELSl qui me servent a saisir l’heure (widget de WINHEX) d’ouverture/fermeture de Chaque Volet

@kiboost
Tu es sur que les WIDGETS sont backupés en V4 ??

Les widgets sont en base oui, ceux du core (outils/widget) et le backup prend toute la base.

Pourquoi tu ne les a pas, je sais pas . @Loic ?

Bonjour,
Sans voir la log de la restauration impossible de se prononcer

@Loic
Effectivement ily a une erreur dans la restauration je ne l’avais pas vu.
Merci

[START RESTORE]
Début de la restauration de Jeedom 2019-11-14 11:19:11
Envoie l’événement de début de restauration…OK
Vérifiez les droits…
OK
Fichier utilisé pour la restauration : /var/www/html/install/…/backup/backup-Jeedom-4.0.27-2019-11-14-11h09.tar.gz
Backup database access configuration…Can not copy /var/www/html/install/…/core/config/common.config.php
OK
Disable all task
… OK
Disable all scenario.

… OK
Décompression de la sauvegarde…
OK
Supprimer la table de la sauvegardeDésactive les contraintes…OK
Supprimer la table : aprescouchésoleil …OK
Supprimer la table : apreslevésoleil …OK
Supprimer la table : avantcouchésoleil …OK
Supprimer la table : avantlevésoleil …OK
Supprimer la table : cmd …OK
Supprimer la table : config …OK
Supprimer la table : cron …OK
Supprimer la table : dataStore …OK
Supprimer la table : eqLogic …OK
Supprimer la table : eqReal …OK
Supprimer la table : history …OK
Supprimer la table : historyArch …OK
Supprimer la table : interactDef …OK
Supprimer la table : interactQuery …OK
Supprimer la table : listener …OK
Supprimer la table : message …OK
Supprimer la table : note …OK
Supprimer la table : object …OK
Supprimer la table : plan …OK
Supprimer la table : plan3d …OK
Supprimer la table : plan3dHeader …OK
Supprimer la table : planHeader …OK
Supprimer la table : scenario …OK
Supprimer la table : scenarioElement …OK
Supprimer la table : scenarioExpression …OK
Supprimer la table : scenarioSubElement …OK
Supprimer la table : update …OK
Supprimer la table : user …OK
Supprimer la table : view …OK
Supprimer la table : viewData …OK
Supprimer la table : viewZone …OK
Restauration de la base de données…
ERROR 1071 (42000) at line 995: Specified key was too long; max key length is 767 bytes
OK
Active les contraintes…OK
Restauration du cache…OK
Check jeedom consistency…[START CONSISTENCY]
[START CHECK AND FIX DB]

Fix : CREATE TABLE IF NOT EXISTS widgets (
id int(11) NOT NULL AUTO_INCREMENT,
name varchar(255) NOT NULL,
type varchar(27) NULL,
subtype varchar(27) NULL,
template varchar(255) NULL,
display text NULL,
replace text NULL,
test text NULL,
primary key(id))
ENGINE InnoDB;

CREATE UNIQUE INDEX unique ON widgets (type ASC,subtype ASC,name ASC)[END CHECK AND FIX DB]
Check jeedom database…OK

Check filesystem right…
OK
[END CONSISTENCY]
OK
Enable scenario : OK
Enable task : OK
Envoie l’événement de la fin de la sauvegarde…ERREUR [MySQL] Error code : 42S22 (1054). Unknown column ‹ type › in ‹ field list › : SELECT id, name, isActive, group, mode, schedule, scenarioElement, trigger, timeout, object_id, isVisible, display, order, description, configuration, type
FROM scenario
WHERE mode != « schedule » AND isActive=1 AND trigger LIKE :cmd_idTemps de la restauration : 60s
Fin de la restauration de Jeedom
[END RESTORE SUCCESS]

Ton backup source était sur un jeedom bien a jour ?

V 4.0.27
Fichier utilisé pour la restauration : /var/www/html/install/…/backup/backup-Jeedom-4.0.27-2019-11-14-11h09.tar.gz

Ilsemblerait que monter MariaDB à la version 10.3 resoudrait ce probleme.

@Loic
Je viens de m’apercevoir que le backup source provient d’un raspberry PI3 sous VERSION=« 10 (buster) » et la destination RPI3 également mais sous VERSION=« 9 (stretch) ».

Confirme moi quand même si tu penses que c’est ça.
Cdlt

A ben oui clairement c’est ca pas meme version de db donc pas meme longueur max des index

Désolé de t’avoir dérangé. J’aurais du approfondir avant.
Merci