New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Homematic: cannot see/modify variables #18984
Comments
If you have a CCU you have to provide a username and password (to the hosts-section) as mentioned here in the documentation. Without proper credentials Home Assistant is not allowed to query the JSON-RPC API. |
Thank you for the quick reaction. Now I got to actually test your suggestion. In fact I use Homematic without authentication and authorization - the system is open. You may discuss whether this is good but so far I did not have problems. Now I configured a guest user, as the documentation suggests and placed the credentials into the configuration like this:
But after a restart of HomeAssistant the logfile still contains messages like this one: I noticed though that now I have an entity |
Ah, the abovementioned variable rollosollwert may have come through some other configuration change that I tried:
This would also explain why other variables from the CCU2 are not available on HomeAssistant. |
That doesn't matter. To access the JSON-RPC API a username and passwort always are required. Even if you don't set them on the CCU, it internally does some authentication transparently. At least I didn't get it to work back then when I have implemented that. So that's why credentials always are required. The problem with the variables is still caused by your configuration. You also have to add the credentials in the hosts-section. Make it look like this: homematic:
interfaces:
wireless:
host: 192.168.178.39
resolvenames: json
username: homeassistant
password: nLGWekp3
rf:
host: 192.168.178.39
resolvenames: json
username: homeassistant
password: nLGWekp3
hosts:
ccu2:
host: 192.168.178.39
username: homeassistant
password: nLGWekp3
local_port: 8124 |
I added credentials to the hosts/ccu2 part as you suggested. After a restart the error message I described is no longer visible, now I can see this in the logfile:
This looks as promising as strange. Pyhomematic writes the method when succesful while it should tell it when unsuccessful. But next I checked the UI to see the values. The environment variables are still not visible, and all the devices are missing now. Seems like the autodiscovery is impacted now. The "configuration check" function returns ok though. |
I just noticed another error in your configuration: you have not specified a port for your second interface. You have The log you have posted is perfectly fine. That's exactly how it looks like if it's working correctly. The variables are all part of the attributes of a single entity. In your case the name should be Please read the documentation again. All of this is described there in great detail. If you follow the instructions closely you shouldn't run into any troubles. |
I turned off my default view to see all devices, and it seems all of
them got renamed from serial number based to the friendly name I had
configured on Homematic. That is a step forward already. The variables
however do not show up even when I investigate the "homematic.ccu2"
entity. It only shows friendly_name and icon attributes.
For the interfaces: I actually only use Homematic with wireless
devices. There is no wired device connected, and I have no Homematic IP
devices. Would I still have to configure the interfaces?
I'm sorry but actually I had tried to follow the one page
documentation, and this is where I ended up. Which documentation are
you referring to?
…On Sat, 2018-12-08 at 13:22 -0800, Daniel Perna wrote:
I just noticed another error in your configuration: you have not
specified a port for your second interface. You have wireless and rf.
I suppose one of them is for the old wireless devices, and the other
for HomeMatic IP. For HomeMatic IP you have to specify the port 2010.
The way you have it right now you are connecting twice to the same
port, which would just load all device two times. I never tested this
though, so that might be why you're not seeing anything right now.
The log you have posted is perfectly fine. That's exactly how it
looks like if it's working correctly. The variables are all part of
the attributes of a single entity. In your case the name should be
homematic.ccu2. Go to the states panel (< >-button in the left menu),
there you'll find the entity. The variables will be part of the
details you can see there. You should also see the variables simply
by clicking on the entity in the regular UI.
Please read the documentation again. All of this is described there
in great detail. If you follow the instructions closely you shouldn't
run into any troubles.
If you run into further issues, please open a thread in the
community. The issues here at GitHub are intended for bugs and alike.
In the community you'll meet a bigger audience with more chances of
getting seen by people who are able to help you.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c5
5493e4bb","name":"GitHub"},"entity":{"external_key":"github/home-
assistant/home-assistant","title":"home-assistant/home-
assistant","subtitle":"GitHub repository","main_image_url":"
https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open
in GitHub","url":"
***@***.***
in #18984: I just noticed another error in your configuration: you
have not specified a port for your second interface. You have
`wireless` and `rf`. I suppose one of them is for the old wireless
devices, and the other for HomeMatic IP. For HomeMatic IP you have to
specify the port `2010`. The way you have it right now you are
connecting twice to the same port, which would just load all device
two times. I never tested this though, so that might be why you're
not seeing anything right now.\r\n\r\nThe log you have posted is
perfectly fine. That's exactly how it looks like if it's working
correctly. The variables are all part of the attributes of a single
entity. In your case the name should be `homematic.ccu2`. Go to the
states panel (`\u003c \u003e`-button in the left menu), there you'll
find the entity. The variables will be part of the details you can
see there. You should also see the variables simply by clicking on
the entity in the regular UI.\r\n\r\nPlease read the documentation
again. All of this is described there in great detail. If you follow
the instructions closely you shouldn't run into any troubles.\r\nIf
you run into further issues, please open a thread in the [community](
https://community.home-assistant.io/). The issues here at GitHub are
intended for bugs and alike. In the community you'll meet a bigger
audience with more chances of getting seen by people who are able to
help you."}],"action":{"name":"View Issue","url":"
#18984 (comment)
"}}}
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "
#18984 (comment)
",
"url": "
#18984 (comment)
",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
***@***.***": "MessageCard",
***@***.***": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [home-assistant/home-assistant] Homematic: cannot
see/modify variables (#18984)",
"sections": [
{
"text": "",
"activityTitle": "**Daniel Perna**",
"activityImage": "
https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": ***@***.***",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
***@***.***": "ActionCard",
"inputs": [
{
"isMultiLine": true,
***@***.***": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
***@***.***": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\":
\"IssueComment\",\n\"repositoryFullName\": \"home-assistant/home-
assistant\",\n\"issueId\": 18984,\n\"IssueComment\":
\"{{IssueComment.value}}\"\n}"
}
]
},
{
"targets": [
{
"os": "default",
"uri": "
#18984 (comment)
"
}
],
***@***.***": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
***@***.***": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\":
419285113\n}"
}
],
"themeColor": "26292E"
}
]
|
Then there should be something relevant in the log. You don't need to have debug loggin on. If this fails, then there should be a message in the
Of course. Otherwise Home Assistant wouldn't know about the CCU. And in your case you onle need 1 interface, since you only use the regular wireless devices. The documentation says: |
Hi Daniel,
it seems we are getting somewhere. Yes, the text you formatted in
italics is what I see in the documentation. The explanation that each
interface has by design it's own port is not visible there. You did not
design the CCU2 but somehow I also would not first study homematic APIs
before configuring homematic.
So it is quite obvious one would not have to configure interfaces that
would not show devices anyway, and therefore I commented out the 'ip'
and 'groups' interfaces. But I was unsure what the 'hosts' list does in
addition. So maybe introducing a bit this concept would help. Also if
username/password are definitely required the code coudl emit a warning
or error message so users like me get a better hint what may be
missing.
The Resolvenames option is described as it can be turned on and off.
But the impact is not mentioned. So I believe it could help to say
without resolvenames the devices would be named by
devicetype.serialnumber, while with resolvenames it is (I am guessing
now) devicetype.group.devicename. As I had turned off the default view
to make only my own groups visible, all unassigned devices are not
shown so in fact I had lost my devices since all the entity ids have
changed.
But now I noticed something good: For the first time one of my
automation scripts was able to turn off lamps. Until now I was able to
control them manually, and automation could turn them on but never off.
That is why I had debug logging for homematic enabled anyway.
Another thing is that the environment variables still do not show up in
my HomeAssistant. I went through the logs and could not find a single
of my names in there. Something is still in the dark, and I may need
help to investigate what that might be. Getting a procedure here may
help me and others if collected in a troubleshooting guide.
I had a look at pyhomematic source and compared it to the log output I
see. This location was definitely passed:
https://github.com/danielperna84/pyhomematic/blob/f1482ff6fe061b5ee82d434272e36cf98764db38/pyhomematic/_hm.py#L684So
now I have to guess whether it bails out at line 687, which is
unlikely since I see some logout message as well.Next is the condition
in line 692. Somehow I believe here the code hides that Homematic may
have sent an error message. Maybe it is worth a warning or even error
message in the (missing) else block?
What do you think?
Hiran
…On Sat, 2018-12-08 at 18:55 -0800, Daniel Perna wrote:
> The variables however do not show up even when I investigate the
> "homematic.ccu2" entity. It only shows friendly_name and icon
> attributes.
Then there should be something relevant in the log. You don't need to
have debug loggin on. If this fails, then there should be a message
in the warning or error level.
> I actually only use Homematic with wireless devices. There is no
> wired device connected, and I have no Homematic IP devices. Would I
> still have to configure the interfaces?
Of course. Otherwise Home Assistant wouldn't know about the CCU. And
in your case you onle need 1 interface, since you only use the
regular wireless devices. The documentation says:
(list) (Required) Configuration for each XML-RPC interface to
integrate into Home Assistant.
An XML-RPC interface is what Home Assistant is using to read and
write data from and to the devices. By desing each type (wired,
wireless and IP) has it's own port (2000, 2001 and 2010). 2001 is the
default, since most people have the regular wireless devices like you
do. That's why in your case you can leave out the port. The
documentation I am referring to is this one:
https://www.home-assistant.io/components/homematic/
The second paragraph tries to sum up what I have explained here. If
you feel the explanation given in the documentation is not clear
enough, please tell me how to improve it so other users won't run
into the same issues.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c5
5493e4bb","name":"GitHub"},"entity":{"external_key":"github/home-
assistant/home-assistant","title":"home-assistant/home-
assistant","subtitle":"GitHub repository","main_image_url":"
https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open
in GitHub","url":"
***@***.***
in #18984: \u003e The variables however do not show up even when I
investigate the \"homematic.ccu2\" entity. It only shows
friendly_name and icon attributes.\r\n\r\nThen there should be
something relevant in the log. You don't need to have debug loggin
on. If this fails, then there should be a message in the `warning` or
`error` level.\r\n\r\n\r\n\r\n\u003e I actually only use Homematic
with wireless devices. There is no wired device connected, and I have
no Homematic IP devices. Would I still have to configure the
interfaces?\r\n\r\nOf course. Otherwise Home Assistant wouldn't know
about the CCU. And in your case you onle need __1__ interface, since
you only use the regular wireless devices. The documentation
says:\r\n_(list) (Required) Configuration for each XML-RPC interface
to integrate into Home Assistant._\r\nAn XML-RPC interface is what
Home Assistant is using to read and write data from and to the
devices. By desing each type (wired, wireless and IP) has it's own
port (2000, 2001 and 2010). 2001 is the default, since most people
have the regular wireless devices like you do. That's why in your
case you can leave out the port. The documentation I am referring to
is this one:
https://www.home-assistant.io/components/homematic/\r\nThe second
paragraph tries to sum up what I have explained here. If you feel the
explanation given in the documentation is not clear enough, please
tell me how to improve it so other users won't run into the same
issues."}],"action":{"name":"View Issue","url":"
#18984 (comment)
"}}}
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "
#18984 (comment)
",
"url": "
#18984 (comment)
",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
***@***.***": "MessageCard",
***@***.***": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [home-assistant/home-assistant] Homematic: cannot
see/modify variables (#18984)",
"sections": [
{
"text": "",
"activityTitle": "**Daniel Perna**",
"activityImage": "
https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": ***@***.***",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
***@***.***": "ActionCard",
"inputs": [
{
"isMultiLine": true,
***@***.***": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
***@***.***": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\":
\"IssueComment\",\n\"repositoryFullName\": \"home-assistant/home-
assistant\",\n\"issueId\": 18984,\n\"IssueComment\":
\"{{IssueComment.value}}\"\n}"
}
]
},
{
"targets": [
{
"os": "default",
"uri": "
#18984 (comment)
"
}
],
***@***.***": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
***@***.***": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\":
419285113\n}"
}
],
"themeColor": "26292E"
}
]
|
They are not required because not everybody needs those. There are people that use Homegear instead of a CCU, and there the reuquirements are different. Hence we can't show a warning because what would be a warning with the CCU is totally fine with Homegear and vice versa.
Well, it's not directly stated, that's correct. But in this conext in seems to have never occurred to anyone, that it could be unclear what the option does. If you don't set it you get the device IDs. What "resolve names" does seems intuitive in this context. Besides that it's briefly referenced here (in the paragraph below the example).
Variables don't get logged. You could have hundres of them, and logging them would only unnecessarily bloat the log. All that would be relevant would be an error message when it fails to read the variables. But as mentioned in my post above, please check if you even allow access to the needed API.
It's not missing. There are various legitimate reasons why the code can pass this point. And we only want to gather variables in this specific case. Every other case can, but not must be an error. |
The firewall is not the issue. It is configured for full access with a
limitation in the IP range.Since HomeAssistant did not complain about
logging on, showed the expected devices but just did not transfer any
environment variables I guess this was never an issue.
Meanwhile I can see environment variables under homematic.ccu2, and I
successfully modified one via the respective service. You may want to
check out this thread to see what I did:
https://community.home-assistant.io/t/homematic-variables-not-working-2/83703
Thank you for your support. Maybe you can add something of this
experience to the documentation or the code, as it would make other
people lives a bit easier. :-)
Hiran
…On Sun, 2018-12-09 at 13:05 -0800, Daniel Perna wrote:
Regarding the variables: do you actually allow connections to the
JSON API? On the CCU2 the Firewall Settings have to like this:
"Vollzugriff" would be ok as well, although that's not very secure.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c5
5493e4bb","name":"GitHub"},"entity":{"external_key":"github/home-
assistant/home-assistant","title":"home-assistant/home-
assistant","subtitle":"GitHub repository","main_image_url":"
https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open
in GitHub","url":"
***@***.***
in #18984: Regarding the variables: do you actually allow
connections to the JSON API? On the CCU2 the Firewall Settings have
to like this:\r\n\u003cimg width=\"404\" alt=\"hms\" src=\"
https://user-images.githubusercontent.com/7396998/49702892-4e605080-fbfe-11e8-8105-41ec34c36214.png\"\u003e\r\n\"Vollzugriff\
" would be ok as well, although that's not very
secure."}],"action":{"name":"View Issue","url":"
#18984 (comment)
"}}}
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "
#18984 (comment)
",
"url": "
#18984 (comment)
",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
***@***.***": "MessageCard",
***@***.***": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [home-assistant/home-assistant] Homematic: cannot
see/modify variables (#18984)",
"sections": [
{
"text": "",
"activityTitle": "**Daniel Perna**",
"activityImage": "
https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": ***@***.***",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
***@***.***": "ActionCard",
"inputs": [
{
"isMultiLine": true,
***@***.***": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
***@***.***": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\":
\"IssueComment\",\n\"repositoryFullName\": \"home-assistant/home-
assistant\",\n\"issueId\": 18984,\n\"IssueComment\":
\"{{IssueComment.value}}\"\n}"
}
]
},
{
"targets": [
{
"os": "default",
"uri": "
#18984 (comment)
"
}
],
***@***.***": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
***@***.***": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\":
419285113\n}"
}
],
"themeColor": "26292E"
}
]
|
On Sun, 2018-12-09 at 13:48 -0800, Daniel Perna wrote:
> Also if username/password are definitely required the code coudl
> emit a warning or error message so users like me get a better hint
> what may be missing.
They are not required because not everybody needs those. There are
people that use Homegear instead of a CCU, and there the
reuquirements are different. Hence we can't show a warning because
what would be a warning with the CCU is totally fine with Homegear
and vice versa.
I did not know about that. Is it possible to query for the device
HomeAssistant actually connects to? I've never used a HomeGear...
> The Resolvenames option is described as it can be turned on and
> off. But the impact is not mentioned.
Well, it's not directly stated, that's correct. But in this conext in
seems to have never occurred to anyone, that it could be unclear what
the option does. If you don't set it you get the device IDs. What
"resolve names" does seems intuitive in this context. Besides that
it's briefly referenced here (in the paragraph below the example).
Apart from that: you can turn off resolvenames again and get back to
the ID-based names. You just have to stick to one or the other. The
problem with resolving names is that if for some reason you rename
the device on the CCU, it will also change the ID in Home Assistant,
and therefore break all related automations etc..
Yes, that is what I ultimately did: I turned off the name resolution.
> I went through the logs and could not find a single of my names in
> there.
Variables don't get logged. You could have hundres of them, and
logging them would only unnecessarily bloat the log. All that would
be relevant would be an error message when it fails to read the
variables. But as mentioned in my post above, please check if you
even allow access to the needed API.
Since I do not have any other API client for the CCU2 and up to now did
not even bother about user privileges that was all a first time
experience. Not your fault, though.
> Maybe it is worth a warning or even error message in the (missing)
> else block?
It's not missing. There are various legitimate reasons why the code
can pass this point. And we only want to gather variables in this
specific case. Every other case can, but not must be an error.
Is that the case? Then I am wondering why this line looks exactly as I
suggested for getting variables:
https://github.com/danielperna84/pyhomematic/blob/f1482ff6fe061b5ee82d434272e36cf98764db38/pyhomematic/_hm.py#L795
Plus the fact that only with that message I was able to resolve the
issue, which was the user's privileges on the CCU2 side.
Hiran
|
Using Homegear is an active process. It's an alternative to the CCU. So for CCU users it's irrelevant, and people that use Homegear know that they are using it.
Setting a variable and failing at that could have negative impacts. Lets say you want to trigger some kind of alarm on your CCU. If that fails that could be really bad. |
On Sun, 2018-12-09 at 14:34 -0800, Daniel Perna wrote:
> I did not know about that. Is it possible to query for the device
> HomeAssistant actually connects to? I've never used a HomeGear...
Using Homegear is an active process. It's an alternative to the CCU.
So for CCU users it's irrelevant, and people that use Homegear know
that they are using it.
So if I understand correctly there is no way pyhomematic can figure out
itself whether it is talking to HomeGear or HomeMatic. But this
information seem crucial to validate whether other configuration
directives make sense or not.
Since users know which of the two systems they have, how about adding
an attribute to the configuration where exactly this is specified?It
seems easy for them to deliver the information, and based on that some
validation can then give further information which items are missing or
bad. This would be an improvement in usability.
> Is that the case? Then I am wondering why this line looks exactly
> as I suggested for getting variables:
Setting a variable and failing at that could have negative impacts.
Lets say you want to trigger some kind of alarm on your CCU. If that
fails that could be really bad.
On the other side, the list of varialbes on the CCU can change, and
maybe even be empty. It's been too long since I made this, so I don't
know exactly what was the issue. But there are responses the CCU
gives that are no problem, but are not worth logging. An explicit
condition where where has been an error could be logged of course.
I agree it does not matter why you introduced logging. There was a
problem, and there may be problems in the future as well.But are you
aware about priorities? If I am concerned of a bloated logfile, I just
turn off verbosity. In my case I was worried about functionality so I
configured to have all message logged (debug) . Right now I am not
happy when the system hides information that can help troubleshooting.
If this were my code I would - similar like all the events and values
for each device are logged - introduce a logger that logs all
environment variables and their values - debug priority is sufficient.
As soon as someone feels comfortable with the setup he'd switch to less
verbose logging anyway.
A troubleshooting section could then look like this:- Configure the
system according to the documentation- Use HomeAssistant validate
configuration to check- Turn up logging for these loggers (list them)
and check the logfile for indicated problems
Hiran
… {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c5
5493e4bb","name":"GitHub"},"entity":{"external_key":"github/home-
assistant/home-assistant","title":"home-assistant/home-
assistant","subtitle":"GitHub repository","main_image_url":"
https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open
in GitHub","url":"
***@***.***
in #18984: \u003e I did not know about that. Is it possible to query
for the device HomeAssistant actually connects to? I've never used a
HomeGear...\r\n\r\nUsing Homegear is an active process. It's an
alternative to the CCU. So for CCU users it's irrelevant, and people
that use Homegear know that they are using it.\r\n\r\n\u003e Is that
the case? Then I am wondering why this line looks exactly as I
suggested for getting variables:\r\n\r\nSetting a variable and
failing at that could have negative impacts. Lets say you want to
trigger some kind of alarm on your CCU. If that fails that could be
really bad.\r\nOn the other side, the list of varialbes on the CCU
can change, and maybe even be empty. It's been too long since I made
this, so I don't know exactly what was the issue. But there are
responses the CCU gives that are no problem, but are not worth
logging. An explicit condition where where has been an error could be
logged of course."}],"action":{"name":"View Issue","url":"
#18984 (comment)
"}}}
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "
#18984 (comment)
",
"url": "
#18984 (comment)
",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
***@***.***": "MessageCard",
***@***.***": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [home-assistant/home-assistant] Homematic: cannot
see/modify variables (#18984)",
"sections": [
{
"text": "",
"activityTitle": "**Daniel Perna**",
"activityImage": "
https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": ***@***.***",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
***@***.***": "ActionCard",
"inputs": [
{
"isMultiLine": true,
***@***.***": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
***@***.***": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\":
\"IssueComment\",\n\"repositoryFullName\": \"home-assistant/home-
assistant\",\n\"issueId\": 18984,\n\"IssueComment\":
\"{{IssueComment.value}}\"\n}"
}
]
},
{
"targets": [
{
"os": "default",
"uri": "
#18984 (comment)
"
}
],
***@***.***": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
***@***.***": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\":
419285113\n}"
}
],
"themeColor": "26292E"
}
]
|
It actually is possible to detect, but it doesn't make sense since you have to a) follow the documentation anyways, and b) don't necessarily require all options the CCU provides. I don't resolve names, and you don't do it as well. So we can't just say we need a username just because someone uses the CCU. And there are even more options than CCU and Homegear. hassio has a add-on that acts as an interface as well, and there you also don't need a username or password. It really iss dependent on any individual case. Besides that Home Assistant already has it's config validation for required and optional options. I do see the point in making things easier. But this is outside of the scope for HomeMatic and mor of an architectural decision of how Home Assistant in general handles configurations. For which there are already plans. It's mentioned somewhere in the developer documentation, so it's on their roadmap.
Seeing the values of variables wouldn't have helped fixing your problem. If you see them in the entity it did work, so logging them is obsolete. If you don't see them in the entity, there wouldn't be anything to log. |
On Mon, 2018-12-10 at 16:13 -0800, Daniel Perna wrote:
> So if I understand correctly there is no way pyhomematic can figure
> out itself whether it is talking to HomeGear or HomeMatic. But this
> information seem crucial to validate whether other configuration
> directives make sense or not.
>
> Since users know which of the two systems they have, how about
> adding
>
> an attribute to the configuration where exactly this is
> specified?It
>
> seems easy for them to deliver the information, and based on that
> some
>
> validation can then give further information which items are
> missing or
>
> bad. This would be an improvement in usability.
It actually is possible to detect, but it doesn't make sense since
you have to a) follow the documentation anyways, and b) don't
necessarily require all options the CCU provides. I don't resolve
names, and you don't do it as well. So we can't just say we need a
username just because someone uses the CCU.
What about the combination:
A user uses CCU AND wants to resolve names AND did not give
username/password?
But this is outside of the scope for HomeMatic and mor of an
architectural decision of how Home Assistant in general handles
configurations. For which there are already plans. It's mentioned
somewhere in the developer documentation, so it's on their roadmap.
That sounds good. Somehow I miss strong validation in YAML, as it used
to be possible with XML and XSDs and even on JSON there is some JSON
Schema.
Seeing the values of variables wouldn't have helped fixing your
problem. If you see them in the entity it did work, so logging them
is obsolete. If you don't see them in the entity, there wouldn't be
anything to log.
Yes, we could log more error messages. But honestly: in around 2
years of Home Assistant + HomeMatic you're the first user I have
witnessed that got stuck because of insufficient permissions of the
user. But that's something that should be part of the documentation.
Which is lacking this information right now. But that's easy to fix.
Yes, we could log more error messages. But honestly: in around 2
years of Home Assistant + HomeMatic you're the first user I have
witnessed that got stuck because of insufficient permissions of the
user. But that's something that should be part of the documentation.
Which is lacking this information right now. But that's easy to fix.
Don't get too much stuck on the variable values. I would have liked to
have a similar pattern as you already implemented for the device
values.
But that is more or less optional.
What is way more crucial if something unforeseen happens that may break
the whole automation - not just setting values.
When I look at my internal URL http://ccu2/api/homematic.cgi I see this
text:
Die HomeMatic JSON API vereinheitlicht Zugriff auf die verschiedenen
Teile der HomeMatic Zentrale unter einer einheitlichen Schnittstelle.
Diese Schnittstelle basiert auf JSON-RPC, einer Form des entfernen
Prozeduraufrufs, der auf JSON aufsetzt.
Following the JSON RPC specification, item 1.2 looks like this:
1.2 Response ¶When the method invocation completes, the service must
reply with a response.
The response is a single object serialized using JSON.
It has three properties:
result - The Object that was returned by the invoked
method. This must be null in case there was an error invoking the
method.
error - An Error object if there was an error invoking
the method. It must be null if there was no error.
id - This must be the same id as the request it is
responding to.
So from this I conclude that either the response has a result that
pyhomematic may use, or it contains an error since there is nothing for
pyhomematic to use. Let's go back to the first URL to see what possible
error codes the CCU can emit:
Fehlercodes
FehlercodeKurzbeschreibung
100Ungültige Anfrage
101Das Element id fehlt in der Anfrage
102Das Element method fehlt in der Anfrage
103Das Element params fehlt in der Anfrage
200Ungültige Antwort
201Das Element id fehlt in der Antwort
202Das Element result fehlt in der Antwort
203Das Element error fehlt in der Antwort
300Interner Fehler
400Privilegstufe reicht nicht
401Methode nicht gefunden
402Argument nicht gefunden
5xxAnwendungsspezifische Fehler
When looking at those, I believe there is not a single one that should
be silently swallowed by pyhomematic. Therefore I still believe
whenever an "error" node exists it should definitely get logged.
If this does not convince you I do not know what else to do. We can
definitely stop disagreeing here.
Hiran
|
Just ran into the same problem and found this thread a little too late. On the plus side, I was down to a TCP dump and this clearly shows the problem:
But pyhomematic will not tell you anything about it, even with debug logging enabled. |
Home Assistant release with the issue:
0.83.2
Last working Home Assistant release (if known):
never worked for me
Operating environment (Hass.io/Docker/Windows/etc.):
Docker running homeassistant/home-assistant:latest
Component/platform:
https://www.home-assistant.io/components/homematic/
Description of problem:
Homematic environment variables are not visible in Home Assistant, devices and their states show up ok. The situation only showed up as a problem when I tried moving automation from Homematic to Home Assistant and needed access to some variables.
Problem-relevant
configuration.yaml
entries and (fill out even if it seems unimportant):Traceback (if applicable):
not available
Additional information:
Home Assistant logfile shows messages like
2018-12-03 21:28:44 DEBUG (SyncWorker_13) [pyhomematic._hm] ServerThread.getAllSystemVariables: Exception: <Fault -1: 'getAllSystemVariables: unknown method name'>
The text was updated successfully, but these errors were encountered: