20-1-2016.
Continuando con la tarea de mantener una base de datos libre de datos incongruentes, esta vez me estoy dedicando a limpiar los datos del punto de rocío. Este dato lo calcula y lo entrega en un principio la propia estacion meteorológica. Como digo es un dato calculado y se apoya en la humedad relativa y la temperatura exterior para su cálculo. Bien pues como es de todos sabido, esta estación nos da esporádicamente unos valores que no se corresponden con la realidad. Concretamente y estos días atrás he estado corrigiendo valores extremos y absurdos de temperatura. Estos valores también le afectaban como he dicho al cálculo del punto de rocío. En esa misma ocasión podría haber corregido ambos, pero para no complicarme y liarme pues no lo hice. Ahora me encuentro en ese menester.
El procedimiento es muy similar al ya realizado anteriormente, con la salvedad que al pedir el volcado de la base datos tengo que sacar los datos de outTemp y outHumidty para llevarlo a una calculadora de punto de rocío y calcularlo. En internet hay muchas páginas que hacen esta tarea. Si es cierto que no me queda otra que hacerlo uno por uno, y si no lo hubiera dejado tanto pues no tendría tanto trabajo. En el siguiente enlace puedes ver un ejemplo de ello. Es el que estoy usando:
Calculadora de punto de rocío
Para facilitar un paso de conversión en la fecha, me estoy ayudando de la funcion datetime() de sqlite. Con esta función puedo mostrar la fecha que se guarda en la BBDD en el formato unixepoch en un formato mas amigable y entendible dd-mm-aa hh:mm:ss.
Su uso sería:
datetime(dateTime,'unixepoch')-->dateTime sería el nombre del campo en el registro de la BBDD. No confundir con el nombre de la función sqlite.
De esta manera es mas fácil de localizar la incongruencia.
Blog dedicado a la recopilación de eventos e incidencias relacionados tanto con la estación meteorológica como la Raspberry Pi.
Mostrando entradas con la etiqueta web. Mostrar todas las entradas
Mostrando entradas con la etiqueta web. Mostrar todas las entradas
miércoles, 20 de enero de 2016
jueves, 14 de enero de 2016
Corrección de incongruencias en datos de la BBDD.
14-1-2016.
Estos días atrás me he estado dedicando a resolver los fastidiosos datos erróneos que de vez en cuando y no se porque aparecen registrados en la BBDD.
Que haya un registro erróneo de lluvia lo puedo aceptar, se puede mover el pluviómetro por sacudidas de viento o como ahora que tengo la estación en mantenimiento y la he bajado a la terraza por lo que la recogida de lluvia no es fiable. Pero que de vez en cuando me registre una temperatura de -29 grados es lo que no entiendo. El caso es que este dato como se utiliza para calcular otro como puede ser el punto de rocío pues ya son dos los datos que aparecen anómalos en las gráficas. Esos son los fastidiosos picos que aparecen en las gráficas.
Bien pues como ya he aprendido a modificar esos datos, bien fácil que es, solo los tengo que localizar en la BBDD y promediarlo con los datos aledaños, anterior y posterior. Aunque sea una modificación a mano creo que es la manera de no alterar mucho la realidad, le asignamos un valor que se acerca al real ya que se tiene en cuenta la tendencia en ese momento entre 5 minutos antes y 5 minutos después.
Una vez actualizada la BBDD, y siguiendo el procedimiento de Tom Keffer, borro las tablas de DAILY o datos diarios y las vuelvo a generar.
A partir de aquí no tengo muy claro como se resuelve el resto. Lo que si me he dado cuenta es que el resultado no aparece inmediatamente, al menos en los resultados anuales que es donde apreciaba los errores. Pero si al cabo de un tiempo. Los gráficos anuales no se generan cada vez que se lanza el proceso REPORTS, ni aunque se lance a mano. Esto lo descubrí al ver que no se modificaban las fechas de los archivos anuales tras una generación. Lo dejé y al poco tiempo ya estaban actualizados. Pero no he descubierto la regla que sigue dicha actualización.
Estos días atrás me he estado dedicando a resolver los fastidiosos datos erróneos que de vez en cuando y no se porque aparecen registrados en la BBDD.
Que haya un registro erróneo de lluvia lo puedo aceptar, se puede mover el pluviómetro por sacudidas de viento o como ahora que tengo la estación en mantenimiento y la he bajado a la terraza por lo que la recogida de lluvia no es fiable. Pero que de vez en cuando me registre una temperatura de -29 grados es lo que no entiendo. El caso es que este dato como se utiliza para calcular otro como puede ser el punto de rocío pues ya son dos los datos que aparecen anómalos en las gráficas. Esos son los fastidiosos picos que aparecen en las gráficas.
Bien pues como ya he aprendido a modificar esos datos, bien fácil que es, solo los tengo que localizar en la BBDD y promediarlo con los datos aledaños, anterior y posterior. Aunque sea una modificación a mano creo que es la manera de no alterar mucho la realidad, le asignamos un valor que se acerca al real ya que se tiene en cuenta la tendencia en ese momento entre 5 minutos antes y 5 minutos después.
Una vez actualizada la BBDD, y siguiendo el procedimiento de Tom Keffer, borro las tablas de DAILY o datos diarios y las vuelvo a generar.
A partir de aquí no tengo muy claro como se resuelve el resto. Lo que si me he dado cuenta es que el resultado no aparece inmediatamente, al menos en los resultados anuales que es donde apreciaba los errores. Pero si al cabo de un tiempo. Los gráficos anuales no se generan cada vez que se lanza el proceso REPORTS, ni aunque se lance a mano. Esto lo descubrí al ver que no se modificaban las fechas de los archivos anuales tras una generación. Lo dejé y al poco tiempo ya estaban actualizados. Pero no he descubierto la regla que sigue dicha actualización.
miércoles, 6 de enero de 2016
Mantenimiento de la base de datos. Weewx.sdb
2016-1-6.
Como arreglar las incongruencias de la base de datos era algo que tenía pendiente y contra mas tiempo pase mas incongruencias se me iban acumulando, hoy he decidido ponerme manos a la obra.
Tras leer el post de Jantoni en el que explica este procedimiento y viendo que en la documentación de Weewx viene también documentado, no he visto mayor problema que seguir las indicaciones.
Como arreglar las incongruencias de la base de datos era algo que tenía pendiente y contra mas tiempo pase mas incongruencias se me iban acumulando, hoy he decidido ponerme manos a la obra.
Tras leer el post de Jantoni en el que explica este procedimiento y viendo que en la documentación de Weewx viene también documentado, no he visto mayor problema que seguir las indicaciones.
- Parar el programa. sudo /etc/init.d/weewx stop
- Ejecutar sqlite3 abriendo la base de datos. O nos ponemos en el directorio /var/lib/weewx o lo direccionamos con el comando:
sqlite3 weewx.sdb. Ojo si no lo hacemos con Sudo asegurarse que con el usuario que estamos trabajando tiene permisos de escritura sobre el archivo. - Realizar las modificaciones que tengamos pendiente, todo sobre la tabla archives. Este es el procedimiento que aconsejan en la documentación de Weewx:
Spikes in the graphs
- Occasionally you may see anomalous readings, typically manifested as spikes in the graphs. The source could be a flaky serial/USB connection, radio or other interference, a cheap USB-Serial adapter, low-quality sensors, or simply an anomalous reading.Sensor quality matters. It is not unusual for some low-end hardware to report odd sensor readings occasionally (once every few days). Some sensors, such as solar radiation/UV, have a limited lifespan of about 5 years. The (analog) humidity sensors on older Vantage stations are known to deteriorate after a few years in wet environments.If you frequently see anomalous data, first check the hardware.To keep bad data from the database, add a quality control (QC) rule such as Min/Max bounds. See the QC section for details.To remove bad data from the database, you will have to do some basic SQL commands. For example, let's say the station emitted some very high temperatures and wind speeds for one or two readings. This is how to remove them:
- stop weewx
- Make a copy of the archive database
cp weewx.sdb weewx-YYMMDD.sdb
- Verify the bad data exist where you think they exist
sqlite3 weewx.sdb sqlite> select dateTime,outTemp from archive where outTemp > 1000;
- See whether the bad temperature and wind data happened at the same time
sqlite> select dateTime,outTemp,windSpeed from archive where outTemp > 1000; - Remove the bad data by setting to NULL
sqlite> update archive set windSpeed=NULL where outTemp > 1000; sqlite> update archive set outTemp=NULL where outTemp > 1000;
- Delete the statistics database so that weewx can regenerate it without the anomalies
- start weewx
- Rehacer las tablas diarias:
pi@raspberrypi:/var/lib/weewx$ wee_database --drop-daily
Using configuration file /etc/weewx/weewx.conf
Using database binding 'wx_binding', which is bound to database 'archive_sqlite'
Proceeding will delete all your daily summaries from database 'weewx.sdb'
Are you sure you want to proceed (y/n)? y
Dropping daily summary tables from 'weewx.sdb' ...
Dropped daily summary tables from database 'weewx.sdb'
pi@raspberrypi:/var/lib/weewx$ wee_database --backfill-daily
Using configuration file /etc/weewx/weewx.conf
Using database binding 'wx_binding', which is bound to database 'archive_sqlite'
Backfilling daily summaries in database 'weewx.sdb'
Backfilled 'weewx.sdb' with 151756 records over 554 days in 1814.17 seconds
pi@raspberrypi:/var/lib/weewx$
martes, 5 de enero de 2016
Vuelta a la normalidad. Página web funcionando de nuevo.
2016-1-5.
Tras poner en marcha el entorno de pruebas, reconozco que es una gozada modificar cualquier cosa referente a la página web. De hecho el error que estaba sufriendo y que me ha obligado a poner la página por defecto que trae weewx durante un par de días lo he subsanado en un rato. Lejos de aplicar un conocimiento profundo de programación que no poseo, lo he aislado eliminando código y añadiendolo poco a poco hasta que me ha vuelto a dar el error. Si ya se que es bastante chapucero pero no poseo conocimiento para mas....como dicen en mi entorno, tengo el conocimiento justo pa echar el día....
Bueno pues el caso es que me las he apañado para subsanarlo y otra vez vuelve a esta operativa mi página web y ademas con la mejora del Feed RSS de mi blog.
No es el que quería poner pero de momento se va a quedar hasta que consiga poner en marcha el script que me ha estado dando problemas.
Tras poner en marcha el entorno de pruebas, reconozco que es una gozada modificar cualquier cosa referente a la página web. De hecho el error que estaba sufriendo y que me ha obligado a poner la página por defecto que trae weewx durante un par de días lo he subsanado en un rato. Lejos de aplicar un conocimiento profundo de programación que no poseo, lo he aislado eliminando código y añadiendolo poco a poco hasta que me ha vuelto a dar el error. Si ya se que es bastante chapucero pero no poseo conocimiento para mas....como dicen en mi entorno, tengo el conocimiento justo pa echar el día....
Bueno pues el caso es que me las he apañado para subsanarlo y otra vez vuelve a esta operativa mi página web y ademas con la mejora del Feed RSS de mi blog.
No es el que quería poner pero de momento se va a quedar hasta que consiga poner en marcha el script que me ha estado dando problemas.
Preparando el entorno de pruebas. Segunda Parte.
2016-1-5.
Tras configurar y dejar funcionando el registro de log's del entorno de pruebas, paso a configurar el espacio de pruebas. Esto basicamente se basa en los siguientes puntos:
Tras configurar y dejar funcionando el registro de log's del entorno de pruebas, paso a configurar el espacio de pruebas. Esto basicamente se basa en los siguientes puntos:
- Crear un archivo pruebas.conf basado en el archivo weewx.conf. Este está situado en el directorio /etc/weewx/.
- Editar este archivo para que las páginas que se generen lo hagan en el directorio dedicado a ello. El apartado a modificar es el siguiente:
[StdReport]
# Where the skins reside, relative to WEEWX_ROOT
SKIN_ROOT = /etc/weewx/pruebas
# Where the generated reports should go, relative to WEEWX_ROOT
HTML_ROOT = /mnt/var/www/pruebas - Copiar el directorio Skins completo en otro llamado pruebas, quedará situado en el directorio apuntado por Skin_Root del punto anterior. Esto no es obligatorio, podemos llevarnos todo esto al espacio que nos de la gana tanto de la Sd como del disco duro si lo tuvieramos.
- Crear un espacio Pruebas donde alojar las páginas generadas de prueba y que estas puedan ser servidas por el servidor WEB. En mi caso como tengo todo alojado en el disco duro pues le creo un directorio como apunta en HTML_ROOT del punto 3. Tal como se crea este directorio no se puede ver desde el servidor web, ya que el servidor sirve las páginas desde /var/www. Tengo que crear un enlace simbólico desde el disco duro a la Sd. El comando sería este:
ln -s /mnt/var/www/pruebas/ /var/www/pruebas
De esta manera ya se puede ver desde internet. - Si todo está correcto podemos comenzar a lanzar el primer comando de pruebas:
sudo wee_reports /etc/weewx/pruebas.conf
Si no lanzamos el comando con sudo nos da error de permisos, ya que weewx se instaló y corre bajo root, sus directorios y archivos le pertenecen y aunque son accesibles como lectura no se dejan sobreescribir ya que somo pi o el usuario correspondiente con el que nos logueemos. - Podemos realizar el seguimiento del resultado de la generación de las páginas con el comando:
tail -f /path hacia el archivo log/wee_reports.log
Preparando el entorno de pruebas. Primera parte
2016-1-5.
Bueno pues como de los errores se aprende, tras el último estropicio que ha sido el cargarme la página principal de la estación (index.html), acometo lo que tenía que haber hecho hace ya tiempo.
Con esta entrada documento el principio de lo que voy a llamar el entorno de pruebas o desarrollo, según he estado viendo por internet también se le llama sandbox. Esto creo que es una alegoría a lo que hacen los niños pequeños en los parques, pues eso jugar en un cajón de arena.
Como he aprendido a probar las modificaciones realizadas en la plantilla sobre la marcha sin esperar a que cumpla la temporización por el proceso principal WEEWX, lo primero es separar las acciones y los mensajes generados por ambos procesos diferenciados.
El proceso que lanzo para probar es el WEE_REPORTS. Por tanto lo primero es redirigir los mensajes que genere este proceso a un archivo log independiente para poder visualizarlos y llevar un seguimiento de los resultados.
La tarea de mantener un registro de todos los mensajes la realiza el proceso RSYSLOG del SO.
Este proceso por defecto lee todos los archivos de configuración que se incluyan en su directorio RSYSLOG.D. Bueno pues he copiado el archivo de configuración existente 99-weewx.conf en el archivo 99-wee_reports.conf y lo he modificado quedando de esta manera:
:programname,startswith,"wee_reports" /mnt/var/log/wee_reports.log
:programname,startswith,"wee_reports" ~
El proceso Rsyslog se lanza con el sistema operativo y funciona permanentemente.
Como este archivo se está alimentando continuamente de mensajes y mas si es de pruebas, pues como el resto de los archivos log's lo voy a incluir en la tarea LOGROTATE para que se reciclen de tal manera que cambie de nombre y se compriman cada cierto periodo de tiempo.
Para ello hago algo parecido a lo anterior.
La tarea LOGROTATE por defecto tambien lee todos los archivo *.conf que existen en su directorio /etc/logrotate.d/, por lo que copio el archivo weewx en el archivo wee_reports y lo modifico quedando de la siguiente manera:
/mnt/var/log/wee_reports.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 644 syslog adm
sharedscripts
postrotate
reload rsyslog > /dev/null 2>&1
endscript
}
Con esto mantengo la misma politica sobre los archivos log's que para el resto de aplicaciones.
El proceso Logrotate se lanza con la tarea CRON y es ejecutado cada cierto tiempo según se haya configurado en el demonio CRON. En mi caso se encuentra dentro del directorio cron.daily$, por lo que se lanza diariamente.
Bueno pues como de los errores se aprende, tras el último estropicio que ha sido el cargarme la página principal de la estación (index.html), acometo lo que tenía que haber hecho hace ya tiempo.
Con esta entrada documento el principio de lo que voy a llamar el entorno de pruebas o desarrollo, según he estado viendo por internet también se le llama sandbox. Esto creo que es una alegoría a lo que hacen los niños pequeños en los parques, pues eso jugar en un cajón de arena.
Como he aprendido a probar las modificaciones realizadas en la plantilla sobre la marcha sin esperar a que cumpla la temporización por el proceso principal WEEWX, lo primero es separar las acciones y los mensajes generados por ambos procesos diferenciados.
El proceso que lanzo para probar es el WEE_REPORTS. Por tanto lo primero es redirigir los mensajes que genere este proceso a un archivo log independiente para poder visualizarlos y llevar un seguimiento de los resultados.
La tarea de mantener un registro de todos los mensajes la realiza el proceso RSYSLOG del SO.
Este proceso por defecto lee todos los archivos de configuración que se incluyan en su directorio RSYSLOG.D. Bueno pues he copiado el archivo de configuración existente 99-weewx.conf en el archivo 99-wee_reports.conf y lo he modificado quedando de esta manera:
:programname,startswith,"wee_reports" /mnt/var/log/wee_reports.log
:programname,startswith,"wee_reports" ~
El proceso Rsyslog se lanza con el sistema operativo y funciona permanentemente.
Como este archivo se está alimentando continuamente de mensajes y mas si es de pruebas, pues como el resto de los archivos log's lo voy a incluir en la tarea LOGROTATE para que se reciclen de tal manera que cambie de nombre y se compriman cada cierto periodo de tiempo.
Para ello hago algo parecido a lo anterior.
La tarea LOGROTATE por defecto tambien lee todos los archivo *.conf que existen en su directorio /etc/logrotate.d/, por lo que copio el archivo weewx en el archivo wee_reports y lo modifico quedando de la siguiente manera:
/mnt/var/log/wee_reports.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 644 syslog adm
sharedscripts
postrotate
reload rsyslog > /dev/null 2>&1
endscript
}
Con esto mantengo la misma politica sobre los archivos log's que para el resto de aplicaciones.
El proceso Logrotate se lanza con la tarea CRON y es ejecutado cada cierto tiempo según se haya configurado en el demonio CRON. En mi caso se encuentra dentro del directorio cron.daily$, por lo que se lanza diariamente.
domingo, 3 de enero de 2016
Error en la generación de la página web
2016-1-3. Error generando la página web.
Modificando el template he tenido que hacer algo que me está generando un error y se sale del proceso de generación por lo que la página no se genera.
Este es el error que me da:
Modificando el template he tenido que hacer algo que me está generando un error y se sale del proceso de generación por lo que la página no se genera.
Este es el error que me da:
Jan 3 22:21:25 raspberrypi weewx[24064]: cheetahgenerator: Generate failed with exception '<type 'exceptions.TypeError'>'
Jan 3 22:21:25 raspberrypi weewx[24064]: cheetahgenerator: **** Ignoring template /etc/weewx/skins/Standard/index.html.tmpl
Jan 3 22:21:25 raspberrypi weewx[24064]: cheetahgenerator: **** Reason: tuple indices must be integers, not str
Jan 3 22:21:25 raspberrypi weewx[24064]: **** Traceback (most recent call last):
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "/usr/share/weewx/weewx/cheetahgenerator.py", line 295, in generate
Jan 3 22:21:25 raspberrypi weewx[24064]: **** print >> _file, text
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in __str__
Jan 3 22:21:25 raspberrypi weewx[24064]: **** rc = getattr(self, mainMethName)()
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "cheetah__etc_weewx_skins_Standard_index_html_tmpl_1451856084_5_93744.py", line 1537, in respond
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "cheetah__etc_weewx_skins_Standard_index_html_tmpl_1451856084_5_93744.py", line 672, in __errorCatcher87
Jan 3 22:21:25 raspberrypi weewx[24064]: **** File "<string>", line 1, in <module>
En este momento todavía no he averiguado que es lo que provoca el error, está claro que es el archivo index.html.tmpl ya que lo he cambiado por el que trae la distribución y no provoca el error.
Página para la generación de scripts para la sindicación de Feeds RSS
2016-1-3.
He encontrado la siguiente página Web para la generación de scripts y poder incluirlos en página web. Así podré tener los titulares de un blog por ejemplo. En mi caso mi blog en el que llevo todo lo referente a mi estación meteorológica y todo lo que relacionado con ella.
La dirección de la web es la siguiente:
http://rss.sindicacion.net/
He encontrado la siguiente página Web para la generación de scripts y poder incluirlos en página web. Así podré tener los titulares de un blog por ejemplo. En mi caso mi blog en el que llevo todo lo referente a mi estación meteorológica y todo lo que relacionado con ella.
La dirección de la web es la siguiente:
http://rss.sindicacion.net/
Modificación de la ubicación de la página WEB
2016-1-3. Cambio de la ubicación de los archivos de la página WEB.
Para minimizar los accesos a la tarjeta SD de la Raspberry pi, redirecciono la generación de los archivos del programa weewx al directorio /mnt/var/www/ del disco duro.
Para no tocaar la configuración del servidor Apache creo un enlace simbólico del archivo /var/www/weewx a la ubicación de los archivos de la página web /mnt/var/www/ para que se sirva la página web.
La dirección de acceso a la página web sigue siendo la misma.
Para minimizar los accesos a la tarjeta SD de la Raspberry pi, redirecciono la generación de los archivos del programa weewx al directorio /mnt/var/www/ del disco duro.
Para no tocaar la configuración del servidor Apache creo un enlace simbólico del archivo /var/www/weewx a la ubicación de los archivos de la página web /mnt/var/www/ para que se sirva la página web.
La dirección de acceso a la página web sigue siendo la misma.
viernes, 1 de enero de 2016
Modificación rango de temperatura Weewx.conf, apartado StdQc
2016-1-1. Debido a la recepción errónea esporádica de valores extremos de temperatura, modifico el rango de temperatura en el archivo weewx.conf en su apartado de control de calidad StdQc.
dejo los valores acotados entre -10º y 49º de mínimo y máximo. Considero que en esta localización nunca debemos de superar esos márgenes por lo que no son aceptables valores como los que sin saber porque mi estación manda esporádicamente. Espero que con esta modificación queden resueltos estos errores. De momento no se como afectará esta modificación al funcionamiento del programa.
La modificación queda como a continuación:
dejo los valores acotados entre -10º y 49º de mínimo y máximo. Considero que en esta localización nunca debemos de superar esos márgenes por lo que no son aceptables valores como los que sin saber porque mi estación manda esporádicamente. Espero que con esta modificación queden resueltos estos errores. De momento no se como afectará esta modificación al funcionamiento del programa.
La modificación queda como a continuación:
El valor original de temperatura mínima era de -40ºF, que son -40ºC. Lo dejo en 14ºF que son -10ºC. El resto queda tal como estaba.
# This section is for quality control checks. If units are not specified,
# values must be in the units defined in the StdConvert section.
[StdQC]
[[MinMax]]
barometer = 26, 32.5, inHg
outTemp = 14, 120, degree_F
inTemp = 10, 120, degree_F
outHumidity = 0, 100
inHumidity = 0, 100
windSpeed = 0, 120, mile_per_hour
Imagen que muestra el error esporádico que recibo:
jueves, 31 de diciembre de 2015
Instalando Magpierss. Función en PHP para la lectura de feeds RSS.
2015-12-31. Magpierss.
La instalación de esta función se inicia con la descarga del paquete software.
Se puede descargar con wget, este es el comando:
wget http://sourceforge.net/projects/magpierss/files/magpierss/magpierss-0.72/magpierss-0.72.tar.gz
La instalación de esta función se inicia con la descarga del paquete software.
Se puede descargar con wget, este es el comando:
wget http://sourceforge.net/projects/magpierss/files/magpierss/magpierss-0.72/magpierss-0.72.tar.gz
Yo lo he descargado directamente a /home/pi/descargas y he descomprimido el archivo con el comando:
tar -zxf magpierss-0.72.tar.gz
Se crea el directorio magpierss-0.72 con todos los archivos necesarios para su uso.
Según sus instrucciones de instalación y uso, se puede instalar para que sea usado de manera individual para una web en concreto o de manera general para que pueda ser utilizado por todas las páginas servidas por el servidor web. Yo lo he instalado para que se encuentre disponible por el servidor WEB.
El directorio de instalación en mi caso es:
usr/share/php/magpierss
A esta hora me asalta una duda no resuelta y es que al instalar PHP5, que es el php disponible en la red, al instalarse lo hace con todas sus referencias a directorios propios como PHP5, mientras que el path de sus include_path en su configuración es el siguiente:
include_path => .:/usr/share/php:/usr/share/pear => .:/usr/share/php:/usr/share/pear
Según sus instrucciones de instalación y uso, se puede instalar para que sea usado de manera individual para una web en concreto o de manera general para que pueda ser utilizado por todas las páginas servidas por el servidor web. Yo lo he instalado para que se encuentre disponible por el servidor WEB.
El directorio de instalación en mi caso es:
usr/share/php/magpierss
A esta hora me asalta una duda no resuelta y es que al instalar PHP5, que es el php disponible en la red, al instalarse lo hace con todas sus referencias a directorios propios como PHP5, mientras que el path de sus include_path en su configuración es el siguiente:
include_path => .:/usr/share/php:/usr/share/pear => .:/usr/share/php:/usr/share/pear
Como veo una incongruencia y posibilidad de fallo, para no modificar el archivo de configuración de PHP el cual no domino, opto por crear el path usr/share/PHP indicado siendo ya real y existente a la hora de buscar los include posibles de los script. Podía haber renombrado el PHP5 como PHP pero como no se la transcendencia de este directorio lo dejo como está.
pi@raspberrypi:/usr/share$ ls -l |grep 'php'
drwxr-xr-x 5 root root 4096 dic 31 16:22 php
drwxr-xr-x 5 root root 4096 dic 31 15:24 php5
pi@raspberrypi:/usr/share$
lunes, 14 de diciembre de 2015
Modificación página web de la estación.
Modificando la página web para incluir un feed de noticias de mi blog dedicado a la estación meteorológica.
Suscribirse a:
Entradas (Atom)
