SmartStrip - Controllo prese elettriche da web

Uhm... "sketch_nov27a" mi fa pensare che tu abbia scaricato un file solo invece dell'intero repository, è così?

Ho messo lo sketch nella cartella con le librerie, magari devo rivedere l'installazione di tutte quelle lib se sono al posto giusto. però a parte tutto quello che mi interessa del tuo progetto è solo questo

static var_substitution subDateVarSub PROGMEM = {subDateStr, evaluate_date, NULL};
static var_substitution subTimeVarSub PROGMEM =	{subTimeStr, evaluate_time, NULL};
...

static var_substitution *substitutions[] PROGMEM = {
	&subDateVarSub,
	&subTimeVarSub,
...
...

questo non l'ho mai visto, cosa fa sostituisce i caratteri nelle stringhe del PROGMEM?

No, è il supporto per una sorta di "contenuti dinamici" nelle pagine web. Prova il secondo esempio della libreria Webbino e dovresti capire.

L'uso di PROGMEM in questo frangente è solo per risparmiare più RAM possibile.

Ho aggiunto le istruzioni dettagliate per l'installazione al primo post. A questo punto sei moralmente obbligato a seguirle e dirmi se va tutto bene :). Ho anche aggiunto il file html.h al repository, riscaricalo.

Ciao, mi sembra di averle scaricate tutte e messe in una cartelle di nome "nome libreria" senza .h nella cartella libraries dell arduino.
è il percorso giusto?
ti ho postato una foto dell errore, se riesci a capire.

Francamente è un errore che non ho mai visto. Prova ad aggionare tutto, vedi le istruzioni che ho messo al primo post e vediamo se capita ancora!

La macro F() ritorna un const __FlashStringHelper*

#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))

Mentre la get_get_parameter() accetta un __FlashStringHelper*

char *get_get_parameter (__FlashStringHelper *param);

In SmartStrip2.ino ci sono righe come:

param = request.get_get_parameter (F("mac"));

che forzano il passaggio di un puntatore const ad uno non const. Ovviamente ciò è proibito, perché significherebbe passare da read-only a read-write.

Forse la get_get_parameter() dovrebbe essere dichiarata così:

char *get_get_parameter (const __FlashStringHelper *param);

?

Sì beh, ho chiaro quale può essere il problema. Probabilmente è giusto aggiungere il const, ma io non lo riscontro, è questo che non mi quadra.

Se il problema si presenta ancora e la modifica suggerita non lo risolve (perché da qualche altra parte chiamo la funzione con argomenti non const), un workaround potrebbe essere l'aggiunta di:

char *get_get_parameter (const __FlashStringHelper *param) {
  return get_get_parameter (const_cast<__FlashStringHelper *> (param));
}

Però mi piacerebbe capire meglio perché io non riscontro il problema.

Sono ripartito da zero. cancellato tutto, riscaricato tutto con ide 1.01, librerie e modifica x wiz5100 adesso si ferma a:
static Page aboutPage PROGMEM = {about_html_name, about_html, NULL};
con errore:
SmartStrip2:292: error: 'about_html_name' was not declared in this scope

non è che ma convertito tutte le pagine che sono nella cartella \html come è il file html.h nella cartella dello sketch?

le modifiche che ha suggerito anche tuxduino e anche tu ho provato a cercare dove farle, ma non ci arrivo.
ho preso questo arduino per fare una cosa che poi piu o meno si è rivelata il tuo smartstrip, ma è la prima cosa che faccio con arduino

Uhm, il file html.h l'ho aggiunto stamane al repository proprio per evitare di doverlo generare, c'è già in quello che hai scaricato?

ho provato a cercare dove farle, ma non ci arrivo.

Nella dichiarazione di get_get_parameter() (e ovviamente nella sua implementazione nel file .cpp).

Se il problema si presenta ancora e la modifica suggerita non lo risolve (perché da qualche altra parte chiamo la funzione con argomenti non const), un workaround potrebbe essere l'aggiunta di

Se il problema è in effetti quello che ho rilevato io e si presenza in altri casi, la soulzione è aggiugnere const alle eventuali altre funzioni che non hanno questo attributo, non forzare un cast.

mi pare che i problemi precedenti forse sono superati, adesso mi da esclusivamente errori di sostituzione:
static var_substitution subDateVarSub PROGMEM = {subDateStr, evaluate_date, NULL};
con errore:
SmartStrip2:791: error: too many initializers for 'var_substitution'
SmartStrip2:791: error: invalid conversion from 'char* ()(void)' to 'char* (*)()'

e da solo questi di errore, circa una quindicina

Quello è perché non hai aggiornato Sukkino, l'ho sistemato stamattina!

@tuxduino: Me ne rendo conto, infatti ho parlato di workaround, non di soluzione definitiva. Vorrei capire bene qual è il problema!

Grande SukkoPera, adesso va, ma nell arduino uno non ci entra, il compilato viene 35K, ti risulta?

comunque adesso sto aspettando che mi arrivi il mega2560 e li non ci dovrebbero essere piu problemi.

ma tu avevi detto che l' hai fatto per l' uno o mi sbaglio?

comunque grazie per l' aiuto che mi hai dato appeno arriva il mega lo provo

SukkoPera:
Quello è perché non hai aggiornato Sukkino, l'ho sistemato stamattina!

@tuxduino: Me ne rendo conto, infatti ho parlato di workaround, non di soluzione definitiva. Vorrei capire bene qual è il problema!

Il vero problema è capire come mai compila... :stuck_out_tongue:

Beh sì, l'ho scritto anche qualche post fa! Ho fatto un po' di confusione. La piattaforma di sviluppo principale è una DINo (quindi tipo Arduino Pro + ENC28J60), ma usavo anche una Uno con shield Wiz5100, che però ho dovuto passare a una Mega proprio perché il binario non ci stava più. Se leggi qualche post fa do anche qualche dettaglio in più.

Comunque sulla Uno + Wiz5100 dovrebbe starci quando aggiungerò il supporto per usare un termistore come sensore di temperatura al posto del DS18B20 (la libreria OneWire e la stessa Dallas portano via parecchio spazio). Vorrei anche rendere proprio del tutto opzionale il supporto a tale sensore, perché non è detto che serva a tutti. E magari aggiungere il supporto ad un timer per chi preferisce avere prese temporizzate. Insomma, di idee ne ho, di tempo poco. Se qualcuno volesse aiutare...

Comunque grazie per avere provato il frutto del mio lavoro. Come vedi era ben lungi dalla perfezione, ma grazie a te e agli altri che hanno commentato, ora è migliorato :).

@tuxduino: Se non compilasse avrei già corretto l'errore... Per inciso, la tua soluzione non è detto che funzioni, perché da qualche parte potrei chiamare get_get_parameter() con un argomento che non è const, per questo ho proposto una soluzione alternativa, che fa sì che la chiamata funzioni con argomenti const e non const. Comunque vedrò di fare chiarezza, i cast piacciono poco anche a me.

Diciamo che il 18b20 per me è indispensabile in quanto ho idea di utilizzarlo per gestire la temperatura in casa e se ci riesco lo vorrei espandere circa ad 8 zone.
ho cercato un po in rete e a livello di precisione (.5 gradi) e a livello di distanza su bus semplice, anzi teoricamente forse funziona a 2 fili) puo fare 25 metri e non credo che esista un sensore migliore di questo ad un prezzo accettabile (sono ben accette delle smentite, ma bisogna rimanere sotto i 10 euro a sensore)
per quanto riguarda l' aiuto nessun problema, le modifiche o implementazioni ti terro al corrente.
Ciao

Yep, nella modalità "parasite power" il 18b20 funziona a due fili, pur con alcune limitazioni (principalmente la velocità di lettura, ma nel tuo caso non dovrebbe essere un problema critico). Però potresti prendere in considerazione anche i DHT11/22, che ti permettono di misurare anche l'umidità, vedi qua: Overview | DHT11, DHT22 and AM2302 Sensors | Adafruit Learning System.

Comunque il tuo progetto è interessante, discutiamone insieme! Sarei ben lieto di lavorarci.

ce li ho gia, non servono a niente, leggono +- un grado, non hanno i decimali, ovvero dopo la virgola è sempre 0 quindi o leggono 20 o 21 e per un termostato ambiente nonè sufficiente come precisione, al massimo potrebbe andare bene il mezzo grado.
comunque oggi è arrivato il 18b20 e adesso lo provo.
i dht11 si leggono in 250ms, questo?

Per quel che ne so, il DHT11 si legge massimo una volta al secondo, e può ritornare dati vecchi di qualche secondo. Quanto impieghi la lettura in sé non lo so. Credo comunque che il DS18B20 sia più veloce e più preciso (e io l'ho pure pagato meno!). Così, a naso (quindi non fidarti, potrei dire castronerie, dai un occhio al datasheet), credo si parli di qualche decina di ms, che diventano centinaia se alimentato in parasite power.

Mi piacerebbe tanto scrivere una libreria che astragga l'uso dei vari DHT11, DS18B20, termistori, ecc, tramite un'unica interfaccia, ma ogni astrazione porta via spazio in RAM e flash, che sulle nostre MCU sono le risorse principali :(.