En un artículo anterior abandoné el intento de publicar la información recogida en pachube en formato EEML. Después de un par de días de intentos infructuosos aparqué temporalmente el tema, estaba seguro de que cometía un error «tonto».
Tal como pensaba se trataba de un error bastante tonto, haciendo unas pruebas de publicar desde un gateway de Digi me he dado cuenta.
La información enviada por el microprocesador a través de ethernet era la siguiente:
PUT /api/feeds/6900.xml HTTP/1.1
User-Agent: Fluffy Arduino Ver 0.01
Host: www.pachube.com
Accept: */*
X-PachubeApiKey: 2f06b6065c164ffa2c237b2979e648782236892244d3a7304a68d3965836a817
Content-Length: 323
Content-Type: application/xml; charset=utf-8<?xml version=»1.0″ encoding=»UTF-8″?>
<eeml xmlns=»http://www.eeml.org/xsd/005» xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance» version=»5″ xsi:schemaLocation=»http://www.eeml.org/xsd/005 http://www.eeml.org/xsd/005/005.xsd«>
<environment>
<data id=»0»>
<value>22.50</value>
</data>
</environment>
</eeml>
En la cabecera Content-Length se le pasa al pachube el número de bytes enviados, el método que he utilizado para contarlos es pegar el texto en un documento de word y mirar en las propiedades el número de carácteres.
Ese ha sido el problema, al final de cada línea hay un retorno de carro y un salto de línea, por lo que hay que sumar al número de carácteres el número de líneas multiplicado por dos.
La respuesta del servidor ahora es:
HTTP/1.1 200 OK
Server: nginx/0.6.34
Date: Sun, 02 May 2010 22:03:15 GMT
Content-Type: application/xml; charset=utf-8
Connection: keep-alive
X-Runtime: 96
Cache-Control: private, max-age=0, must-revalidate
Content-Length: 1
Set-Cookie: _pachube_app_session=53fd7ebfd466997621d24f108aa465e0; path=/; expires=Sun, 02 May 2010 23:03:15 GMT; HttpOnly
Vary: Accept-Encoding
En la depuración del problema intenté utlizar el Telnet de Windosw para diagnosticar, mi objetivo era hacer un telnet por el puerto 80 a www.pachube.com, pegar el texto y ver la respuesta, pero tampoco funcionaba. El telnet de Windows intenta hacer un «hello» por el puerto, con lo que la respuesta del servicio web de pachube es inválida. La solución es utilizar un cliente de Telnet que permita hacer conexiones RAW, como el PuTTY.
Ahora ya tenemos al micro enviando los resultados a Pachube por Ethernet:
Una vez más se confirma mi teoría, cuando te «atascas» y has agotado todos los recursos «razonables», lo mejor es dejar de pensar unos días. Puedes trabajar en otras cosas, al final la solución viene como por arte de magia…..
Pingback: Motes: tercete, sacando la información de la red Zigbee | Zigbee labs