Mobile Alerts Temperatur und Luftfeuchte Sensoren in Fhem

[Laffer72]

Super, vielen Dank, funktioniert bei mir jetzt auch wieder.

Kleiner Tipp, falls sicher der Server wieder ändert: Wire Shark ist nicht unbedingt nötig.
Einfach die IP von Mobile-Alerts Gateway in den Browser eingeben und unter Data Server IP steht der Server für den Abruf.

Schönes Wochenende

Reinhard

[Bara]

Hallo Zusammen,
Ich bin ganz neu in Fhem eingestiegen und lese schon eine ganze Zeit mit.
Jetzt habe ich mich mal getraut meinen bestehenden mobile alerts entsprechend den hier sehr schön und gut beschriebenen Vorlagen in Fhem einzubinden.
Hat auch alles wunderbar geklappt . Hier mal meinen besten Dank.

Jetzt hat's ja am Wochenende einen Wintereinbruch gegeben mit den entsprechenden Minus Temperaturen.
Leider schreibt mein Plot für den Aussenfühler nur positive Werte , alles was unter 0 Grad liegt wird nur mit Null angezeigt. Habe ich etwas falsch gemacht oder besteht bei Euch auch dieses Problem?
Viele Grüße Bara

[josburg]

...
Jetzt hat's ja am Wochenende einen Wintereinbruch gegeben mit den entsprechenden Minus Temperaturen.
Leider schreibt mein Plot für den Aussenfühler nur positive Werte , alles was unter 0 Grad liegt wird nur mit Null angezeigt. Habe ich etwas falsch gemacht oder besteht bei Euch auch dieses Problem?
Viele Grüße Bara

Hallo,
ich weiß nicht, nach welcher Doku Du vorgegangen bist.
Für mich habe ich selber eine Doku zusammengestellt unter
http://raspberrypi.crmvy3qiisdstf8c.myfritz.net/wordpress/?page_id=75 bzw.
http://raspberrypi.crmvy3qiisdstf8c.myfritz.net/wordpress/?page_id=29

In meiner Doku hatte ich einen Fehler und habe diesen hier
http://raspberrypi.crmvy3qiisdstf8c.myfritz.net/wordpress/?page_id=29
korrigiert.

Diese Zeile:
attr SENSOR_HUETTE reading01Regex "t1": (\d?\d.\d)
muss ersetzt werden durch:
attr Sensor_HUETTE reading01Regex "t1": ([\-\d\.]+)

Folgenden Termo-/Hygrosensor habe ich im Einsatz:
http://www.amazon.de/gp/product/B00NHY108M/ref=as_li_tl?ie=UTF8&camp=1638&creative=19454&creativeASIN=B00NHY108M&linkCode=as2&tag=jensosburaspu-21


...dann sollte das Ganze auch im Winter klappen...

Viele Grüße
Jens

[Bara]

Hallo Jens,
Vielen herzlichen Dank; gleich ausprobiert und tatsächlich werden jetzt Minustemperaturen angezeigt.
Bin gespannt ob ich jemals in solche Tiefen vorstoßen werde um so einen Fehler selbst zu erkenne.
Beste Grüße aus dem verschneiten Bayern
Bara

[costa2]

Habe heute erst Mobile Alerts in FHEM über HTTPMOD eingerichtet. Einfach als URL http://23.97.212.128:8080/api/v1/dashboard eingeben und alles klappt prima. (hat mir Wireshark verraten )

Gruß,

André

Seit Gestern 11:55 Uhr erhalte ich wieder keine Daten.

Code Auswählen Erweitern

2015.12.19 11:10:18 3: SENSOR_AUSSEN: Defined with URL http://23.97.212.128:8080/api/v1/dashboard and interval 420
2015.12.19 11:10:19 3: WASHINGTONIA_KRONE: Defined with URL http://23.97.212.128:8080/api/v1/dashboard and interval 420
2015.12.19 11:10:19 3: SENSOR_BODEN: Defined with URL http://23.97.212.128:8080/api/v1/dashboard and interval 420
2015.12.19 11:10:20 1: Including ./log/fhem.save
2015.12.19 11:10:20 1: usb create starting
2015.12.19 11:10:23 1: usb create end
2015.12.19 11:10:23 0: Featurelevel: 5.7
2015.12.19 11:10:23 0: Server started with 24 defined entities (version $Id: fhem.pl 9934 2015-11-19 10:12:56Z rudolfkoenig $, os linux, user root, pid 29200)
2015.12.19 11:10:24 3: SENSOR_AUSSEN: Read response to Update didn't match any Reading(s)
2015.12.19 11:10:24 3: WASHINGTONIA_KRONE: Read response to Update didn't match any Reading(s)
2015.12.19 11:10:24 3: SENSOR_BODEN: Read response to Update didn't match any Reading(s)

Die Serveradresse hat sich aber scheinbar nicht geändert.

Code Auswählen Erweitern

Data Server Name www.data199.com
Use Proxy No
Proxy Server Name 192.168.0.14
Proxy Port 8000
Data Server IP 23.97.212.128
Last contact 145052094500

RF channel 2

Nach Eingabe von http://23.97.212.128:8080/api/v1/dashboard in den Browser erhalte ich:

{
  "Message": "The requested resource does not support http method 'GET'."
}

Woran liegt es denn nun wieder?

Volker

[Segler]

Ist es möglich, dass Mobile Alerts schon wieder das Protokoll geändert haben? Seit gestern 11:45 bekomme ich keine neuen Werte mehr. Im Gerät bei FHEM steht unter "buf" folgender Eintrag:

Connection: close { "success": false, "errorcode": 1051, "errormessage": "The request parameters are are invalid", "primarydomain": "www.data199.com" }

Es scheint so, als ob die ursprüngliche Abfrage gem http://forum.fhem.de/index.php/topic,40077.msg323855.html#msg323855 nicht mehr funktioniert.

Aktuell geändert hat sich folgendes:
der Wert für devicetoken war füher "empty" und hat nun eine extrem lange Codierung

Im letztem Monat gab es das schon einmal, wobei folgendes geändert wurde.
version und build habe höhere Nummern. Aktuell: version = 1.18 und build ist 219
executable ist von einer web-Adresse (eu.mobile_alerts.mobilealerts) zu "Mobile Alerts" geändert
Nach der Anpassung wurden die Werte damals wieder erneuert. 

Mobile Alerts scheint da wohl öfters was zu ändern.

Das Gateway liefert die Daten an den www.data199.com Server von Mobile Alerts. Die Adresse ist im Gateway fest programmiert. Gibt es nicht die Möglichkeit, das Gateway so umzuprogrammieren, dass die Daten auf dem eigenen Server abgelegt werden, um diese dann in FHEM einzulesen?

[costa2]

Das Gateway liefert die Daten an den www.data199.com Server von Mobile Alerts. Die Adresse ist im Gateway fest programmiert. Gibt es nicht die Möglichkeit, das Gateway so umzuprogrammieren, dass die Daten auf dem eigenen Server abgelegt werden, um diese dann in FHEM einzulesen?

Sicher geht das.
Dazu muss nur die Adresse auf den eigenen Server umgelenkt werden.

Das geht mit diesem Tool: https://www.weatherdirect.com/downloads/GatewayAdminInstall.exe

[costa2]

Das hat mir Wireshark ausgespuckt:

[alterma]

Hallo an alle,

ich melde mich hier als der Programmierer der weiter oben erwähnten iPhone App 'alterMA', die ich in meiner Freizeit für das technoline Mobile-Alerts System programmiert hatte.

Wie ihr weiter oben auch lesen könnt, hat der Hersteller des Systems meine App Anfang Oktober vom Datenempfang ausgeschlossen. Und zwar damals über eine Header Überprüfung - tauchte im Request Header 'alterma' auf, lieferte der Server keine Daten zurück - mit derselben Fehlermeldung wie von 'Segler' oben erwähnt.

Ich möchte nicht die ganze Geschichte noch einmal breittreten - lest einfach unter www.alterma.eu/hesk/ was ich so erlebt habe in den letzten Monaten.

Was ich euch aber hier mitteilen möchte ist: seit Freitag (18.12.2015) scheinen Anfragen an den Datenserver mit einem 'requesttoken' gesichert zu sein. Ich vermute, dass dieser 'requesttoken' ein Hash aus irgendeinem der anderen übermittelten Werte (evtl. dem timestamp oder den device ids) und einem unbekannten String ist. Dieser wird dann serverseitig überprüft und wenn falsch, dann Feierabend. Leicht umzusetzen und extrem wirkungsvoll.

Ihr werdet kaum Erfolg haben, jetzt noch erfolgreich Abfragen durchzuführen. Technoline wünscht es nicht, dass Anwendungen Dritter Datenabfragen über den Server durchführen. Ich hatte mit dem Geschäftsführer von Technoline telefonischen Kontakt, letztlich aber leider ohne Erfolg. Anfangs wurde mir in Aussicht gestellt, dass meine App Daten offiziell abfragen darf, unsere Diskussionen sind dann aber auf Seiten technolines im Sande verlaufen. Warum, weiß ich nicht. Die sollten doch froh sein, wenn man als Drittanbieter Lösungen für ihr System anbietet - aber: man versteht das auf der anderen Seite nicht.

Mein persönlicher Frust über das Mobile-Alerts System hat sich in den letzten Wochen in Gleichgültigkeit gewandelt. Die wollen nicht, ich will jetzt auch nicht mehr.

Soviel von mir an dieser Stelle. Lange Rede, kurzer Sinn: technoline sperrt nicht authorisierte Datenabfragen rigoros aus.

Lesenswert in diesem Zusammenhang: http://zimperlich.de/dumm-dreistes-geschaeftsgebahren/

Liebe Grüße,

Stefan

[costa2]

Hallo Stefan.

Die Sache mit 'alterMA' habe ich damals mit Interesse verfolgt.
Kurz darauf wurde ja auch schon versucht Fhem auszusperren.
Nun scheint es endgültig gelungen zu sein.
Die einzige Alternative wäre nun eine alternative PHP - Serversoft zu schreiben, welche man z.B. auf einem Apache Server auf der Fritzbox (Freetz) oder auf dem Raspberry Pi laufen lassen kann.
Die Datenausgabe des Gateways kann man ja problemlos umleiten.

Dass so etwas möglich ist, hat Skydiver aus dem WXForum anhand des baugleichen LaCrosse Wireless Internet Gateway Model GW1000U ERF-100 bewiesen.
Leider scheint dieser Gateway eine etwas andere Firmware zu haben, unser Gateway läuft damit nicht.
http://www.wxforum.net/index.php?topic=14299.75

Volker

[alterma]

Die einzige Alternative wäre nun eine alternative PHP - Serversoft zu schreiben, welche man z.B. auf einem Apache Server auf der Fritzbox (Freetz) oder auf dem Raspberry Pi laufen lassen kann.
Die Datenausgabe des Gateways kann man ja problemlos umleiten.

Dass so etwas möglich ist, hat Skydiver aus dem WXForum anhand des baugleichen LaCrosse Wireless Internet Gateway Model GW1000U ERF-100 bewiesen.
Leider scheint dieser Gateway eine etwas andere Firmware zu haben, unser Gateway läuft damit nicht.

Der Aufwand dafür wäre, wie ich finde, enorm - keine Sache, die ich ernsthaft angehen würde.

Man hat hier wirklich ein gutes und einfach zu bedienendes System, was aber leider durch völlig unfähige Produktmanager an die Wand gefahren wird. Ein offene Datenabfrage würde dem Hersteller nur Nutzen bringen.

Doch leider hat man Anfangs schon eine totale Fehlentscheidung getroffen: nämlich die Sache mit dem Datenexport nur für Pro Sensoren. Das Pferd von hinten aufzäumen geht nun nicht mehr.

So sieht Innovation in Deutschland aus: man hat ein gutes Produkt, ist aber völlig unfähig etwas darau zu machen. 

LG,

Stefan

[costa2]

Der Aufwand dafür wäre, wie ich finde, enorm - keine Sache, die ich ernsthaft angehen würde.

Nun ja,
die Daten von LaCrosse IT+ (Technoline) Sensoren kann man ja über den Umweg mit einem JeeLink jetzt schon in Fhem einlesen.
Wäre es nicht möglich eine Routine zu integrieren, welche die Daten aus dem Gateway direkt aufbereitet?

Volker

[costa2]

Hier mal das Protokoll.
Oben Android unten Fhem.
Fhem kommt mit der Anfrage nicht sehr weit.

Code Auswählen Erweitern

+++++++++++++++++++
Android:

E)@?asaZ$pWWzYK
5YPOST /api/v1/dashboard HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=utf-8
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.4.4; Elephone P6000 02 Build/KTU84P)
Host: www.data199.com:8080
Connection: Keep-Alive
Accept-Encoding: gzip
Content-Length: 711

devicetoken=APA91bHTobyyKAYeo9LNbvZ7QJDDw21VSi30di_hAciuTpvkpXPRUQC8yETo9EoIPS6BzSUX2A3mE1iIGfhbH8-tm5ltfhc6FsuLBV0vkbuie5Lh53KeaahuI_bfZuC8x1aCiSeiqfY_&vendorid=2651daf8-823f-4db0-ae02-73d73decc772&phoneid=666193373159&version=1.22&build=69&executable=eu.mobile_alerts.mobilealerts&bundle=eu.mobile_alerts.mobilealerts&lang=de&timezoneoffset=60&timeampm=false&usecelsius=true&usemm=true&speedunit=0&timestamp=1450691666&requesttoken=3f79c164c7f46bafa06f129e71458f3d&deviceids=0301548CBC4A,08004EA0B619,090005AC99E2,107EEEB46F02,0B002FA7C3D3,0315A0114432,022BD216FD85,02083FB10BAC,020A02D7B397,03149A8BAD0B,031555F35085,0239ECDD294F,&measurementfroms=1450605266,,,,,0,,,,0,0,&measurementcounts=,,,,,50,,,,50,50,

+++++++++++++++++++++++
Fhem:

EM@x;DaDYMsRE
bHTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 146
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Mon, 21 Dec 2015 10:19:53 GMT
Connection: close

{
  "success": false,
  "errorcode": 1051,
  "errormessage": "The request parameters are are invalid",
  "primarydomain": "www.data199.com"
}

[costa2]

So, es läuft wieder TEILWEISE.

Wireshark hat mir diesen String ausgespuckt:

Code Auswählen Erweitern

devicetoken=APA91bHTobyyKAYeo9LNbvZ7QJDDw21VSi30di_hAciuTpvkpXPRUQC8yETo9EoIPS6BzSUX2A3mE1iIGfhbH8-tm5ltfhc6FsuLBV0vkbuie5Lh53KeaahuI_bfZuC8x1aCiSeiqfY_&vendorid=2651daf8-823f-4db0-ae02-73d73decc772&phoneid=xxxxxxxxxx&version=1.22&build=69&executable=eu.mobile_alerts.mobilealerts&bundle=eu.mobile_alerts.mobilealerts&lang=de&timezoneoffset=60&timeampm=false&usecelsius=true&usemm=true&speedunit=0&timestamp=1450691666&requesttoken=3f79c164c7f46bafa06f129e71458f3d&deviceids=0301548CBC4A,08004EA0B619,090005AC99E2,107EEEB46F02,0B002FA7C3D3,0315A0114432,022BD216FD85,02083FB10BAC,020A02D7B397,03149A8BAD0B,031555F35085,0239ECDD294F,&measurementfroms=1450605266,,,,,0,,,,0,0,&measurementcounts=,,,,,50,,,,50,50,

Ich habe lediglich die jeweils überschüssigen deviceids entfernt und die jeweiligen Strings in der fhem.cfg ausgetauscht.
Eure Phoneid (xxxxxx) müsst ihr natürlich noch einfügen.

Der Haken an der Sache, es läuft nur bis zum nächsten Datenabruf.
Nach einem "shutdown restart" von Fhem werden wieder aktuelle Daten abgerufen.

Wie kann man das automatisieren?

Edit.

Zur Zeit läuft es wieder stabil.
Ich blicke da nicht mehr durch.

Ps.
Eventuell ist der "devicetoken" bei euch ein Anderer, in dem Fall müsst ihr mal den Wireshark bemühen.

@Stefan.
Der obige String stammt aus einer Android Device mit original App.
Wenn Du nun den String einer Ios Device mit Wireshark ausliest und in deine 'alterMA' App integrierst, geht das nicht?

Volker

[alterma]

@Stefan.
Der obige String stammt aus einer Android Device mit original App.
Wenn Du nun den String einer Ios Device mit Wireshark ausliest und in deine 'alterMA' App integrierst, geht das nicht?

Ich teste das morgen einmal - schaffe das heute zeitlich nicht mehr. Melde mich dann.