list_room_states.py: pmatic.exceptions.PMException #7
Comments
|
Probably related to this I get a similar "PMException" error message when suing the "print_temperature_updates.py" script: |
|
Please add this to the scripts after the "import pmatic" line and run the script again.
From this output we should see which device is causing this issue. Maybe it's the same as in the second trace. Maybe /var/log/syslog contains a useful message. |
|
Thanks for the hint. Here is the output of the device resulting in the error mentioned above (list_room_states.py): Here is a message I receive in /var/log/syslog from the CCU because I connected the syslog output of the CCU to my linux system where I am currently testing pmatic: The device in question (LEQ0079034) is a HM-TC-IT-WM-W-EU device, btw. |
|
Hm, for my HM-CC-RT-DN PARTY_MODE_SUBMIT has a OPERATIONS value of 2 which means that it is only writable and can not be read. So pmatic does not try to read it. For the HM-TC-IT-WM-W-EU operations is set to 3 which means it is read- and writable. This seems to be correct according to the docs (http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf). Maybe this is a general error with this parameter on such devices. I am thinking about either add a generic error handler for dealing with such issues on all kind of devices and channels. For example when a paramset can not be fetched with the 601 error simply set an error internal flag for this paramset and deal with it within pmatic. The other option would be to explicitly ignore the PARTY_MODE_SUBMIT paramset (if only this parameter is bugged). |
|
Thanks for analyzing the issue. I actually think a generic approach would be definitely the better approach since on other devices similar things could happen, thus catching these cases and dealing with these situations in pmatic rather than risking to throw a generic python error would be best. |
|
Having quickly studies the eq3 documentation on the HM-TC-IT-WM-W-EU channels I think PART_MODE_SUBMIT should actually only be writable as well for the HM-TC-IT-WM-W-EU like it is for the HM-CC-RT-DN because this is the only thing that makes sense. The name of the parameter (...._SUBMIT) already implies that the parameter might just be used for actually writing/sending/submitting data and not reading something. Thus I think that the documentation is wrong, which actually this bug is also somehow proofs because otherwise it would be readable as well and wouldn't throw such a JSONRPCError. I would therefore vote to also flag this parameter to write-only together with introducing such a generic exception handler for these situations. |
|
Well, then the documentation and the response of the CCU is wrong. Because the API call is telling that it's read- and writable. This is the communication: It contains this information:
The value 3 of OPERATIONS means that it should be read- and writable. But I agree to rely on the facts. I'll try to make pmatic deal with it. |
|
Perfect. And if it works the we can the report a bug to the occu project (https://github.com/eq-3/occu) so that eq3 can correct for it. |
|
I can also confirm this issue for HM-TC-IT-WM-W-EU. I implemented a fallback to query each parameter one by one with Interface.getValue after the Interface.getParamset call failed to know exactly which parameters are failing. These are the failing parameters for HM-TC-IT-WM-W-EU:
Channel SWITCH_TRANSMIT, parameter DECISION_VALUE Failing parameters for HM-ES-PMSw1-Pl: This is the corresponding log output of the CCU when the calls fail: |
|
The HM-CC-RT-DN device supports something that is called "Wake-On-Radio" in the CCU GUI and, if I remember correctly, burst mode internally. When this is enabled the CCU can wake up the device to make it able to communicate immediately with the CCU. Otherwise the device would only wake up in fixed intervals and initiate the communication with the CCU on it's own. Could you please check whether or not your devices also have such a setting? If so, is it enabled or disabled? Does the behavior change if your change the setting? |
|
Not sure where to look for but I couldn't find anything like "Wake-On-Radio" even for HM-CC-RT-DN. |
|
In the CCU GUI I can find it as follows: Einstellungen > Geräte > Button "Einstellen" beim Gerät > Geräteparameter > Wake-On-Radio |
|
User needs to be in "Expert Mode" to see this setting. Anyway, I can see "Wake on Radio" on both HM-CC-RT-DN and HM-TC-IT-WM-W-EU but the behaviour doesn't change when I uncheck this setting. |
|
Any chance of having this fixed in some short time frame? Or do you still require some more information? |
|
It's finished when it's finished ;-). But yes, I am working on a solution and I think I got a good way to handle the specific issue. One thing to create a test for this case is that I need is the specification of this device and it's logic attributes. Please put this snippet in a .py file, adapt your address and credentials, execute it and either send me the whole resulting files device-specs and device-logic files from your current working directory or extract the information about the single device in question. |
|
Ok, here it comes for the device in question: |
|
Sorry, but after having updated my git checkout and doing a fresh "python setup.py install" I am still getting the same error: Here is the output after having enabled debug mode: |
|
Seems the new customized channel class (pmatic.entities.ChannelThermalControlTransmit) is not used yet. Please execute the following on this device and send me the outpu: |
|
Here it is: |
|
Ah, damn. I totally missed the point that it is not possible to call the generic API call Interface_getParamset on the VALUES paramset because the CCU itself is trying to read the non readable value. So pmatic needs to fetch the values one by one as @jschmer suggested. Will try to fix this this evening. |
|
Sorry, but still no success. Exactly the same error and stack trace here. |
|
Are you sure that it is exactly the same? If so, something might have gone wrong with your installation. You say you executed "python setup.py install" but the traceback contains paths to pmatic like this: "build/bdist.linux-x86_64/egg/pmatic/entities.py". This is no system path where setup.py normally installs the packages to. |
|
This is the path where the pmatic egg files are being installed when I do As soon as I delete these egg files an Thus, the |
|
Hm, okay, then this seems to be fine. And I see, the traceback is not exactly the same. I see the call to "_get_values_bulk" which is in fact a new method I just created. The strange thing is that it should not be called for pmatic.entities.ChannelThermalControlTransmit channels anymore. Instead of this the I'm a bit confused, because some previous debug output said that this class is really used. But maybe another channel/value is also buggy. Could you please a) run the script again in debug mode and send me the output? |
|
It actually really seems to be another channel/value now. See here: (a) (b) |
|
Just pushed a fix for this value. I also tried to improve the error message to be a little more helpful on the API call which produced the error. Hope that was the last broken value. Otherwise I'll try to implement a generic handler for this kind of bug. |
|
Yes, you need a generic handler approach because now it fails for another device: This device is a HM-ES-TX-WM |
|
Seems so, but a value like the energy counter which is only available to be read should really be readable. There is another value for this device named IEC_ENERGY_COUNTER which seems to also provide same values but scaled to kwh instead of kw and with a wider data range. A possible theory: Maybe the ENERGY_COUNTER is a legacy value for the device in your version and can not be read anymore. But to make the whole API call fail seems a bit odd in such a situation. Found another post talking about this issue: http://homematic-forum.de/forum/viewtopic.php?f=27&t=23104&start=200#p254891 the 2nd post might be interesting (resetting/readding the device). Some others on the forum say a reboot of the CCU might help. While I was searching the forum it seemed that this kind of error can occur for a lot of devices with a lot of different values. I am not sure if it's best to just skip fetching those values and leave them at the default Please try the attached script. It will produce a lot of output on the devices, channels, parameters and values. It should automatically fallback to the single value fetching and output the parameter names which can not be fetched. |
|
See the output of your script: I really dunno why this device creates an exception again. However, it works fine and doesn't show any error on the CCU or any related function. |
|
Wir bekommen das schon noch hin ;-). Versuchs mal hiermit. |
|
Na das will ich doch hoffen, denn ich setze viel Hoffnung in pmatic in Zukunft meine komplette Programmierung der CCU zu ersetzen denn HMS Skripte zu betrieben geht einfach mit einer CCU ab einer gewissen Anzahl von Programmen nicht mehr. Die Stabilität geht da einfach in die Knie wie du sicher weisst. So, nun bricht das script zumindest nicht mehr ab und macht entsprechend weiter. Allerdings wirst du in der Debugdatei die ich hier hochlade auch erkennen können das es schon für eine recht große Menge von Devices es zu den besagten "JSONRPCError: TCL error" Exceptions kommt. Wäre schön wenn du klären könntest ob man diese beseitigen könnte oder rausbekommt warum diese Exceptions so häufig auftreten und wie man bzw. du damit umzugehen hast. |
|
Noch ein paar Fragen:
|
Auch muss man sagen treten die Exceptions immer für die selbe Art von Devices auf wie du aus dem Log heraus erkennen kannst. D.h. ich habe z.B. drei HM-ES-TX-WM Devices und alle bringen die selbe Exception. Das spricht meiner Meinung nach gegen ein speichergeartetes bzw. zufälliges Problem. Was ich aber wahrnehmen kann ist das während der Ausführung des skriptes die CPU Auslastung gerade beim ReGaHSS Prozess doch schon merklich hochgeht. Wie genau setzt denn in dem Fall du die Abfrage der CCU aus pmatic heraus um? Durch XML-RPC calls oder wie bezieht pmatic die Daten von der CCU? |
|
Du könntest vielleicht noch mal probieren pmatic direkt auf der CCU auszuführen. Aber ich verspreche mir wenig davon, da, wie du schon feststellst, gleichartige Geräte betroffen sind. Dann mache ich mich mal ran da was einzubauen. Pmatic kann sowohl aktiv Daten von der CCU holen, das geht aktuell über die JSON-API, als auch Events der XML-RPC empfangen, dafür muss man aber den Event-Listener nutzen. Das macht man entweder mit dem pmatic Manager oder selber über |
|
FYI: Ich hatte bei den HM-TC-IT-WM-W-EU mal direkt mit XML-RPC versucht die Values der betroffenen Parameter abzuholen, das funktioniert aber genauso nicht. Hört sich irgendwie nach Firmware-Bug oder sowas an. Wobei dann unklar ist wie die CCU die aktuellen Werte dann bekommt. |
|
Das hatte ich auch schon irgendwo gelesen. Man kann schon - glaube ich - noch weiter runter in der Architektur ansetzen, allerdings bin ich bisher noch nicht so weit vorgedrungen. |
|
Habe nun gerade diesen generellen Fallback-Mechanismus eingebaut. Pmatic versucht nun, wenn es einen Parmetersatz nicht laden kann die einzelnen Werte zu holen und überspringt dann die fehlerhaften stillschweigend. Man kann sich die Fehler mit dem Loglevel INFO so ausgeben lassen: Bin neugierig, ob es tut. |
|
Ehrlich gesagt wundert das mich das das nicht funktionieren soll. Ich betreibe hier ja noch CCU.io zusammen mit Dash.UI und CCU.io Highcharts und CCU.io kann die Werte der betroffenen Devices ja auch problemlos abholen und auch anzeigen... Oder übersehe ich da etwas? |
|
Hm, interessant wäre, wie die kommunizieren, also welche APIs bzw. Calls die benutzen. Werde mir mal den Code angucken. |
|
Hier die Ausgabe nach deinen Änderungen: Wie du aus dem Log sehen kannst kommen nun deine [INFO] ausgaben. Interessant daran ist aber, das er trotzdem am Schluss brauchbare werte z.B. für das "Hausanschluss-Wasser" Gerät ausgibt. Hierbei sei einmal darauf hingewiesen das man den HM-ES-TX-WM ja in zwei Modis betreiben kann (Gas/m3 und Strom/kW) und dabei jeweils nur entweder die GAS_ENERGY_COUNTER bzw. ENERGY_COUNTER angebe verwendet werden kann bzw. valide sind. Kann es also gewolltes verhalten sein das hier dann in dem jeweiligen Modi eben das andere Valuepaar einen Fehler zurückgibt? Auch würde mich interessieren warum der HZ-WW-Tempsensor hier zwar bei der Abfrage von Kanal 5/TEMPERATURE einen Fehler zurück gibt aber die Temperaturwerte die dort dann angezeigt werden alle stimmen – bis auf den letzten – der ist 0.00C? Auch hier kann es sein das das wieder gewollt ist? |
|
Es kommt hier übrigens am Schluss doch noch zu einer weiteren fatalen exception :( |
Ja klar, es kommen halt keine echten Werte für die fehlgeschlagenen Parameter raus. Da werden dann Default-Werte angezeigt. Wohingegen die Werte, die geholt werden konnte angezeigt werden.
Ja siehe da. Hätte mir das gleich jemand gesagt... ;-). Dann bleibt nun die Frage, ob man diesen Betriebsmodus auslesen kann und damit kann man dann das Device vernünftig implementieren.
Hier das gleiche. Die ersten 4 Werte kommen, werden daher verarbeitet. Nur beim 5ten Kanal gibt es einen Fehler, daher der Fallback auf den Default-Wert. Könnte es auch dafür eine logische Erklärung geben, wie für den HM-ES-TX-WM, z.b. dass kein Sensor angeschlossen ist oder etwas dergleichen?
Das ist auch wieder seltsam, allerdings ein anderes Problem. Hier liefert vorher Interface.getParamsetDescription() für den Kanal eine Beschreibung der möglichen Werte, da ist NEXT_TRANSMISSION nicht dabei. Beim darauffolgenden Abfragen der Werte mit Interface.getParamset() kommt dann aber ein solcher Wert mit. Und nun, den einfach ignorieren? Muss ich fast, da ich dafür keine Description habe, die mir ein Parameter-Objekt erzeugen kann. |
|
Der letzte Fehler sollte inzwischen übrigens ebenfalls behoben sein. |
|
Ja, er macht jetzt weiter. Aber "behoben" würde ich das noch nicht nennen denn jetzt motzt er ja über das NEXT_TRANSMISSION ;) Die Frage ist wie willst du jetzt mit den restlichen "Fehlern" (wenn man die überhaupt als Fehler bezeichnen kann) umgehen? Ich kann ja hier mal kurz zusammenfassen: (1) HM-ES-TX-WM: Je nach ausgewähltem Modi ist entweder "ENERGY_COUNTER" und "POWER" abfragbar ODER "GAS_ENERGY_COUNTER" und "GAS_POWER": (2) HM-WDS30-OT2-SM: Kanal 5 scheint nur zur Verbindung mit einer HomeMatic-Wetterstation abfragbar zu sein (siehe http://homematic-forum.de/forum/viewtopic.php?f=27&t=18842#p155683 bzw. http://www.fhemwiki.de/wiki/HM-WDS30-OT2-SM_Differenz-Temperatur-Sensor) (3) HM-Sen-MDIR-O-2/HM-Sec-MDIR-2/HM-Sen-MDIR-WM55 (Bewegungsmelder generell): NEXT_TRANSMISSION (siehe http://diy-lab.de/hausautomation/hardware/homematic/hm-sen-mdir-o-2) So die Frage ist wie du nun damit umgehen willst? |
Am Liebsten wäre es, wenn man den Betriebsmodus ermitteln und dann nur die jeweils relevanten Werte abfragen kann. Allerdings habe ich bisher keinen Wert erkennen können, der darüber Auskunft gibt. Vielleicht findest du ja etwas.
Ah ja, interessant. Auch hier wieder: Wenn man das ermitteln kann, z.b. durch Auslesen ob eine Direktverbindung vorhanden ist, dann könnte pmatic das ordentlich behandeln. (3) HM-Sen-MDIR-O-2/HM-Sec-MDIR-2/HM-Sen-MDIR-WM55 (Bewegungsmelder generell): NEXT_TRANSMISSION (siehe http://diy-lab.de/hausautomation/hardware/homematic/hm-sen-mdir-o-2) Naja, seit dem Commit (898448b) schmiert er bei solchen Fehlern nicht mehr ab. Der Wert wird nun einfach ignoriert bzw. wenn man das Loglevel auf INFO stellt eine Logmeldung erzeugt. Wofür der Wert steht weiß ich bisher nicht. Ich würde den Wert erst einmal weglassen und wenn der doch benötigt wird die Spezifikation des Wertes für den Gerätetyp hart codieren, so dass pmatic nicht auf die Spezifikation von der CCU angewiesen ist, die die CCU ja nicht schickt. |
|
Kurzes Update: |
|
Es gibt neue Erkentnisse:
mode=1 liefert die zusätzliche Information ob ein Wert undefined ist oder nicht Die JSON-API bietet den Parameter 'mode' nicht, d.h. beim Versuch einen undefined Parameter zu lesen wird der call immer fehlschlagen. Das ist bei mir der Fall mit dem Funk-Wandthermostat und Kanal 7, Parameter DECISON_VALUE. Das könnte natürlich auch bei den anderen hier diskutierten Fällen/Geräten der Fall sein. |
When using the latest git master sources I get the following error message when trying the
list_room_stats.pyexample script:My CCU is a RaspberryMatic 2.15.5
The text was updated successfully, but these errors were encountered: