[Vittorio]

Il mio scopo era quello di eliminare tutti i vari alimentatori ed i groviglio dei relativi fili di collegamento ai dispositivi concentrando in una scatola Gewiss tutta l’alimentazione; viste comunque le problematiche e concordando con la necessità di semplificare il tutto per ora mi orienterò solo sull’acquisto di un Vs. alimentatore 24V MDR abbandonando il progetto di Backup sul circuito DC a basso voltaggio. Al riguardo però, dammi una ultima dritta che potrebbe anche essere per me una ulteriore soluzione alternativa.

Se sotto ad un piccolo UPS commerciale come da te consigliato mettessi il filo con i 220Volts di ingresso allo alimentatore MDR il tutto potrebbe funzionare ? Ovvero quando la corrente si interrompe il UPS potrebbe tenere in vita per un pò l’alimentatore DC e quindi i dispositivi allo stesso connessi ? Grazie infinite per l’attenzione che mi hai dedicato.

[Vittorio]

Scusa la mia totale ignoranza in materia (sono un bancario)  ma, ritornando alla prima ipotesi che mi piace di più e tarando l’alimentatore in uscita a 24 Volts anziché 28 Volts la coppia di batterie non riuscirebbe comunque a ricaricarsi, magari piu’ lentamente ? (nel caso mi dovresti dire che collegamento fare fra le due batterie 12V per poi allacciarle  al UPS DC DR-UPS40 che ha un solo ingresso + e -).

O forse il problema sorge al momento in cui le batterie alimentano direttamente l’impianto ? ma se è così, in alternativa, non potrei mettere un qualche tipo di marchingegno/limitatore di tensione dai 28 sino al max dei 24 Volts al solo filo di connessione del PC visto che gli altri dispositivi sopportano anche i 28 Volts ?

Grazie e “tranquillo”!!, l’ordine in un modo o nell’altro arriverà.

[Vittorio]

Purtroppo il PC Embedded ha i 24 Volts come massima tensione consentita. Quale potrebbe essere la soluzione alternativa ?

[Vittorio]

Ho perso diverse nottate, ho studiato approfonditamente tutto il software di configurazione e gestione dei termoregolatori e tutto il giro (compreso porte e indirizzi IP) per lo scambio dei dati tra Termoregolatore e ATC2000, tra il convertitore ed il Server ABS e tra questo e l’interfaccia di configurazione e/o gestione. Ho provato tutti i settaggi possibili ed immaginabili ma non ho tolto un ragno da un buco tranne che la convinzione (forse la certezza) che il problema non è la compatibilità di ATC2000 ma il routing interno della comunicazione e dello scambio dei dati.

La interfaccia di configurazione dei loro convertitori (ATM) – presente come funzione aggiuntiva del programma di gestione del termoregolatore – richiede infatti sia l’indirizzo IP e la Porta dove è in ascolto il Convertitore (dati che nel mio convertitore io setto in modalità SERVER e nella fattispecie IP=192.168.1.5 e porta=5600) sia l’indirizzo IP e la porta RS485 dove è in ascolto e dove deve essere inviata la risposta (il SERVER ABS e nella fattispecie IP=192.168.1.6, porta =9999) che a sua volta quando richiesti li restituisce all’interfaccia di gestione e/o configurazione;  questa configurazione nel mio convertitore la posso settare in modalità Client ma non posso contemporaneamente settare ATC2000 con entrambe le configurazioni ovvero farlo lavorare sia in modalità Server che Client e quindi penso ci sia necessità di un routing o reindirizzamento di rete sottostante (marronata???). Non è che ci possa entrare qualche cosa l’attuale Gateway di rete ovvero che debba utilizzare un altro Gateway ovvero impostare qualche routing nel router per fare in modo che ATC 2000 interrogato da un IP su una porta risponda ad un IP su una altra?? io attualmente nella scheda del ATC2000 oltre l’indirizzo IP fisso di rete del convertitore setto anche l’indirizzo del Gateway inserendo quello corrispondente al Router US Robotic che gestisce la LAN (192.168.1.1).

Sta di fatto che il Server ABS, quello che gestisce tutto e che consente di inviare dall’interfaccia le configurazioni o i dati al termoregolatore ovvero di leggere nell’interfaccia i dati ricevuti dal termoregolatore ha come sua porta interna RS485 la 9999 mentre dalla rete si fa raggiungere tramite la Porta TCP 19999. Naturalmente questo server si attiva e risulta perfettamente configurato e funzionante con tutti i riscontri che il software mette a disposizione; lo stesso prende come indirizzo IP quello del computer di rete dove è installato (192.168.1.6) che è lo stesso che usa l’interfaccia di configurazione.

Non posso neppure eseguire una riprova della compatibilità tra ATC2000 ed il termoregolatore tramite la configurazione diretta via Porta Com perché non ho un PC con porta seriale e volendo utilizzare Virtualcomm, poiché vado ad usare la scheda di rete del PC per la connessione ethernet tra PC e convertitore ATC (con Cavo cross) vado automaticamente a creare una connessione di rete che il Server ABS individua cambiando il proprio indirizzo da locale= 127.0.0.1 a quello della scheda di rete 192.168.1.6 e andando a lavorare in rete ripresenta tutte le problematiche già evidenziate.

Cosa posso fare? Quali test posso effettuare senza perdere oltre la testa?? o mi devo rasegnare a buttare alle ortiche ATC2000 , naturalmente limitatamente all’impiego in questa gestione domotica e/o applicazione???

[Vittorio]

Finalmente funzionante !!!!

Però riesco a farlo funzionare solo lasciando nelle istruzioni di uscita dello script = “if (($Ch == “r”) || (time() > $TimeBf+2))”, la sola ipotesi di uscita per timeout=”(time() > $TimeBf+2)” e togliendo invece la condizione di uscita alla lettura del <cr> “($Ch == “r”)”.

Evidentemente, poiché il <cr> è presente sia nella stringa di scrittura in input nel socket, sia nella stringa di risposta del modem letta nel socket, lo script non riesce a distinguere questa ultima.

[Vittorio]

Provando lo script in simulazione tramite tramite la utilility Toolly settata da Server, in effetti lo Script funziona; alla pressione del tasto Send della pagina php la stringa viene inviata e visualizzata nella colonna Terminal di Toolly e inviando da pulsante Cmd1 “Risposta$0D” viene restituita nella casella Answer della pagina php la stringa “Risposta” proprio come nello Screenshot.

Il problema è che quando ripeto la procedura con ATC-2000 lo script non funziona e restituisce in Answer la stringa digitata in Set command e, solo talune volte niente; naturalmente ATC e Modem sono correttamente collegati e funzionanti e rispondono se interrogati da Toolly settata come TCP/IP Client.

Ho verificato anche accuratamente tutte le impostazioni di PHP.ini in riferimento anche al Server dove gira che è IIS 5.1 e avendo scaricato e studiato per molte notti tonnellate di casistiche ed esempi e forum mi sentirei di dire che dal lato PHP dovrebbe essere tutto a posto; ho solo qualche qualche dubbio sui settaggi “session.hash_bits_per_character = 5” e su “Colors for Syntax Highlighting mode” dove non è abilitato alcun codice, ma che non credo influiscano nella fattispecie. Ho anche cambiato IExplorer in Firefox.

Allora il problema dovrebbe essere  nella struttura della stringa di risposta emessa da ATC2000 ovvero in come o perché php non riesce a leggere questo tipo di stringa di risposta e a restituirla  passandola all’echo di risposta. Di fatto apparentemente sembrerebbe che php legga e restituisca la stringa scritta nel Socket in input anziché puntare, leggere e restituire quella ricevuta nel Socket da ATC. Non riesco a capire. Osservo solo che la risposta in Answer è pressoché immediata ovvero che lo script esce subito e mi domando se non sia per caso necessario un comando che consenta una pausa dopo la scrittura in Input nel Socket per per attendere una risposta di ATC prima di dar corso alla lettura della risposta nel Socket ?

[Autore]

Post