Keypad HmIP-WKP - Kanäle als Bedingung (WENN) nicht auswählbar #1846
Comments
jens-maus
changed the title
|
Leider fehlt mir selbst die passende Hardware ( |
jens-maus
added
🏷️ WebUI
|
Der große Unterschied zur CCU3 ist ja, wie ich es bisher mitbekommen habe, dass in RM nur Kanal 0 angeboten wird und in der CCU3 alle (un)geraden? Kanäle, außer Kanal 0. Vielleicht kommt irgendwas durcheinander durch diesen Patch: Sieht erstmal unscheinbar aus, aber vielleicht kann ein WKP-Besitzer in seiner EDIT: ...
if (deviceType == "HmIP-WKP") {
// Channel 1 AND 2 = User 1, Channel 3 AND 4 = User 2 and so on - but we want to show only the first user channel
var chn = parseInt(channelAddress.split(":")[1]),
arUsrNr = ["","1","","2","","3","","4","","5","","6","","7","","8",""];
...nicht mehr passen. |
Hmm, laut der Aussage eines CCU3 - Nutzers:
Kann man bei CCU3 die Kanäle :0 - :16 wählen. |
|
Komisch. Dann verstehe ich den WebUI-Code nicht. |
|
Kommen wir wohl doch nicht drumrum das sich jemand erbarmt und dir oder mir so ein HmIP-WKP spwndiert 😜 |
|
Ein Backup mit angelerntem WKP hilft ja auch schon weiter |
|
gerne kann ich ein backup zur verfügung stellen.Lg |
Alles klar mail ist raus |
|
Wenn das nicht hilft, ich könnte meinen Keypad zur Verfügung stellen. |
|
Nachdem ich nun das Backup von @nemex kurz testen konnte scheint da Problem wohl banaler Natur zu sein, denn bereits im Kanalauswahlfenster scheint nur Kanal 0 aufgelistet zu werden. Siehe hier:
Die Frage wäre also wo/wie genau unterscheidet sich jetzt die Kanalauswahl für dieses Keypad von der Kanalauswahl anderer HmIP Geräte... |
Siehe EDIT im #1846 (comment) Und - Da es mit der CCU3 Firmware funktioniert: Was patcht RM alles an der Mehr Hinweise fallen mir spontan nicht ein |
Ich bin schon dabei da rauszufinden was da schief geht. in /**
* Wendet alle Filter auf einen Kanal an.
**/
match: function(channel)
{
+ var channelTypeName = channel.typeName.toLowerCase();
+ if (channelTypeName == "hmip-wkp") {
+ console.log(channel.name)
+ console.log(this.showReadable)
+ console.log(channel.isReadable)
+ console.log(this.showWritable)
+ console.log(channel.isWritable)
+ console.log(this.showEventable)
+ console.log(channel.isEventable)
+ }
return ((hasUPL(UPL_ADMIN) | channel.isVisible) &&
((this.showReadable & channel.isReadable) ||
(this.showWritable & channel.isWritable) ||
(this.showEventable & channel.isEventable)) &&
(this.showVirtual | !channel.isVirtual) &&
(this.NameFilter.match(channel.name)) &&
(this.DescriptionFilter.match(channel.typeDescription)) &&
(this.AddressFilter.match(channel.address)) &&
(this.RoomFilter.matchArray(channel.rooms)) &&
(this.FuncFilter.matchArray(channel.subsections)));
}, Und da ist das interessante, das für Kanal 0 hier folgendes ausgespuckt wird: .. wohingegen für Kanal 1 und alle folgenden folgendes ausgegeben wird: Und das erklärt zumindest warum die match-Bedingung dann immer fehl schlägt, denn hier ist |
Hmm, das wird ja aus Datenpunkt mit Wird auf der CCU3 eine andere HMIPServer Version ausgeliefert als im OCCU veröffentlicht ist? |
Das ist ein guter Hinweis. Mit dem folgenden curl Aufruf kann man ja die hier muss man natürlich bei Und dann spuckt der folgendes aus: Insofern ist das was die WebUI macht wohl konsistent zu dem was die JSON RPC API hier direkt von der ReGa zurück bekommt, nämlich das der Kanal 1, usw. eben
Das ist ne gute Frage. Leite ich weiter. Die Frage ist jedoch, woher bekommt der diese Infos? Die Gerätebeschreibungen stecken doch nicht im HmIPServer sondern eigentlich in der Geräte-Firmware und werden bei der Inclusion bzw. Anlernen dann entsprechend ausgelesen und übernommen. So zumindest mein Wissensstand. Das würde bedeuten, das das vielmehr ein Geräte-Firmware "Problem" ist bzw. sich dann eine CCU3 mit dem selben Backup exakt gleich verhalten müsste. Das würde dann darauf deuten, das eQ3 hier wohl noch eine neuere/aktuellere Firmware für den HmIP-WKP liegen hat bzw. für das generieren des Videos genutzt hat und damit die Verwirrung bzgl. CCU3 vs. RaspberryMatic WebUI erst ihren Lauf genommen hat. |
Diese These hatte ich schon am 21.05. im verlinkten Thread aufgestellt.
Es gab aber bisher (soweit ich weiß) keine Rückmeldung(en) von CCU3 Nutzern (bei denen die Kanäle verfügbar sind) zur Firmware des Gerätes. |
|
Oder CCU3 Firmware runterladen, entpacken und den HMIPServer mal austauschen. |
Da bin ich gerade schon dabei. :) Nach meinen Analysen scheint es da in der Tat unterschiede bzgl. HMIPServer in CCU3 vs. OCCU zu geben die sich nicht erklären lassen. |
CCU3 3.63.9 release. This should help in identifying certain device description differences between CCU3 and OCCU. This refs jens-maus/RaspberryMatic#1846
should hopefully solve certain device difference issues. This refs #1846.
|
So, nun hab ich den So @mbhomie007, @Ho-Ecker, @nemex dann bitte mit dem nächsten nightly snapshot morgen entsprechend testen und hier Rückmeldung geben. |
|
Kurze Nachreichung: Gerade hab ich das ganze nochmal mit der offiziellen CCU3 3.63.9 durchgespielt und auch dort fehlen Kanäle > 0 in der Kanalauflistung wenn man das Backup von @nemex zurückspielt. D.h. es muss definitiv einen Unterschied im Anlernprozess geben der entweder in den Unterschieden im Und wenn es doch an den |
|
So, und zu guter letzt hab ich jetzt mal die
Und nichtmal eine suche nach Auch sehe ich z.B. im Kanal 2 lediglich den folgenden Datenpunkt der auch nicht auf Alles also ein wenig verworren momentan und ich bezweifle sogar das es einen CCU3 Nutzer gibt der mit der aktuellen 3.63.9 die Kanäle > 0 bzgl. |
Hmm, laut XML sollte es da mehr geben. <!-- User 1 lock -->
<channel type="ACCESS_TRANSCEIVER" version="2" index="1" maxLinks="10" >
<parameter type="config" subtype="16channels_1">ABORT_EVENT_SENDING_CHANNELS</parameter>
<parameter type="config" subtype="default">NUMERIC_PIN_CODE</parameter>
<parameter type="state" subtype="default">PRESS_LOCK</parameter>
</channel>
<!-- User 1 unlock -->
<channel type="ACCESS_TRANSCEIVER" version="2" index="2" maxLinks="10">
<parameter type="config" subtype="16channels_2">ABORT_EVENT_SENDING_CHANNELS</parameter>
<parameter type="state" subtype="default">PRESS_UNLOCK</parameter>
</channel>
... bis User 8Und der Channel Type <channel type="ACCESS_TRANSCEIVER" typeversion="2">
<link role="SENDER">
<type>REMOTE_CONTROL</type>
</link>
<configuration>
<!-- will be overwritten for default values
<parameter>ABORT_EVENT_SENDING_CHANNELS</parameter>
-->
<parameter>ALARM_MODE_TYPE</parameter>
<parameter>ALARM_MODE_ZONE_1</parameter>
<parameter>ALARM_MODE_ZONE_2</parameter>
<parameter>ALARM_MODE_ZONE_3</parameter>
<parameter>ALARM_MODE_ZONE_4</parameter>
<parameter>ALARM_MODE_ZONE_5</parameter>
<parameter>ALARM_MODE_ZONE_6</parameter>
<parameter>ALARM_MODE_ZONE_7</parameter>
</configuration>
<state>
<parameter>ACCESS_AUTHORIZATION</parameter>
</state>
</channel> |
Wo genau ist das her? |
|
Wenn man die HMIPServer.jar in .zip umbenennt (oder im Kontext die .jar direkt mit einem Unzipper öffnet), bekommt man alle Dateien. u.a. die |
|
Gerade von einem anderen User mit Orig. CCU3 bekommen
|
|
Welche Firmwareversion hat sein WKP? |
1.0.8 |
|
Warum eigentlich erst morgen? also ich habe jetzt die Version 531 drauf. leider keine Änderung. Ich habe das WKP neu angelernt. Und es wird nur kanal 0 angeboten.
|
@nemex Weil dann die heute durchgeführten Änderungen durch den nächtlichen Bau-Automaten in den Snapshot-Build eingebaut werden. Und der steht erst morgen zur Verfügung. Also nix 0531... erst 0601 |
Ahhh danke für die Erklärung. Dann doch morgen😅 |
Die Änderungen und die Erstellung der Snapshots kannst du hier verfolgen: |
|
Einen wunderschönen guten morgen. So Version 601 erfolgreich installiert und siehe da es funktioniert 😁
|
|
Das sind ja gute Nachrichten. Musste das Keypad neu angelernt werden? Sitze gerade viele km entfernt und hätte mit dem anlernen für einen Test gerade so meine Probleme. |
Achso nein ich musste es nicht neu anlernen. |
|
Dann fehlen ja nur noch die Übersetzungen für |
|
Aber die fehlen auf der original CCU3 ja auch, oder? Hat EQ3 das vergessen, oder ist es vielleicht überhaupt nicht gewollt, dass diese Bedingung ausgewählt werden kann? Grundsätzlich ist das keypad ja auch ohne die PRESS_[UN]LOCK Bedingung voll Funktionsfähig. Das ist ja eher ein Schönheitsfehler als wirklich relevant für den Betrieb. |
Genau das ist es was momentan wohl noch (auch eQ3 intern geklärt wird). Man hat nun wahrgenommen das es diese HMIPServer.jar unterschiede gibt. Es ist aber wohl so, das der Auf jeden fall ist nun der HMIPServer in RaspberryMatic mit dem in der CCU3 wieder konsistent und das prinzipielle Problem an das sich dieses Ticket/Issue hier anlehnt ist damit wohl behoben. |
Also ich finde schon das es relevant ist für den Betrieb. Sonst arbeitet das Keypad ja nur im Toggelbetrieb. Es wäre schon wichtig auf Lock oder Unlock regieren zu können. Voll funktionsfähig wäre es für mich so nicht. |
Wie kommt man zur der 601 Version ? Mir wird immer noch die 521 Angezeigt. Danke, Grüße Alex |
Das ist keine stable version, sondern eine instabile Entwicklungsversion. |
|
Ok , ja sowas dachte ich mir schon aber ich find irgendwie nicht wo ich die Programmversionen in der Raspberrymatic einstellen kann |
|
Das ist ein sicheres Zeichen dafür, dass du nicht ganz die Zielgruppe für Entwicklungsversionen bist! 🙃 |
|
@jens-maus Vielen Dank für die Mühe! Wann wird die Stable Version erwartet? |
Na es kommt immer doch eine ~ 1x pro Monat raus. Und dazu kann man einen Blick in die Milestones(https://github.com/jens-maus/RaspberryMatic/milestones) des GitHub Projektes werfen. Laut aktuellen Plan hab ich den Release auf den 25.6. terminiert. |
|
Ok, schade, dass es noch so lange dauert. Ich werde diesen Aktor einfach zurücksenden und es anders lösen. Trotzdem danke :) |
Lange? Wow, Ihr Nutzer seid schon ganz schön verwöhnt inzwischen muss ich sagen. Aber wenn du nicht warten kannst oder willst, dann nimm halt auf eigene Gafhr hin einen aktuellen nightly snapshot (siehe https://github.com/jens-maus/RaspberryMatic/releases/tag/snapshots) - beschwer dich dann aber nicht wenn dir alles andere dann um die Ohren fliegt :) |
|
@jens-maus also das ist eine Ausnahme. Die meisten User und auch ich sind begeistert wie schnell du immer ein Update raus bringst. Davon könnten sich andere große Hersteller eine Scheibe abschneiden. Und die Nightly funktioniert bisher perfekt und ohne Probleme. Ich hab sie jetzt einfach draufgelassen😉 |
|
Hier auch nochmal meine verspätete Rückmeldung, dass das Keypad mit dem Nightly Build/Testversion 3.63.9.20220601-9bd32be einwandfrei funktioniert und die Kanäle alle nun als Bedingung auswählbar sind. |
Describe the issue you are experiencing
Keine Kanäle außer Kanal 0 als Bedingung [Wenn] in Programmen auswählbar.
https://homematic-forum.de/forum/viewtopic.php?f=58&t=74115&start=80
Describe the behavior you expected
Alle Kanäle als Bedingung auswählbar, wie in der original CCU-Firmware
Steps to reproduce the issue
What is the version this bug report is based on?
3.63.9.20220521
Which base platform are you running?
rpi3 (RaspberryPi3)
Which HomeMatic/homematicIP radio module are you using?
RPI-RF-MOD
Anything in the logs that might be useful for us?
Additional information
https://youtu.be/G5M14LadFg8
Ab Minute 15:30
The text was updated successfully, but these errors were encountered: