search

giejay / domoticz-gbridge-plugin

Domoticz plugin for the Kappelt gBridge
16 stars 4 forks source link

no support for temperature / thermostat #3

Closed JurikRistjouw closed 5 years ago

JurikRistjouw commented 5 years ago

I've added a temperature sensors and a thermostat device, but i get these errors from domoticz log:

2018-12-14 11:16:50.930 Error: (kapelt gBridge) No gBridge adapter found for device: Room Temperature 2018-12-14 11:16:50.930 Error: (kapelt gBridge) No gBridge adapter found for device: Living Room Thermostat

according to the docs, it should work. Is this a bug or not yet implemented?

kind regards,

Jurik

giejay commented 5 years ago

Woops, I have a temp adapter implemented but I forgot to add the adapter to the list. Will do that tonight.

JurikRistjouw commented 5 years ago

nice! can't wait to pull ;)

giejay commented 5 years ago

I added support for Setpoints and Im able to set the temperature of my room. Asking what the temperature currently is, is not supported yet.

JurikRistjouw commented 5 years ago

i keep having some trouble, what command are you giving to make the setpoint change?

giejay commented 5 years ago

Hey Google, set the 'device name' to 22 works for me

JurikRistjouw commented 5 years ago

Ah, thanx

mine is called: "Living Room Thermostat". When I call for set living room thermostat to 22. I get: this mode isn't available for 2 thermostats (i only have one, i've also opened an issue for that on gbridge github)

edit: after deleting the device from the kapelt device page and update on the domoticz hardware tab, i get a response like this: "this mode isn't available for the living room thermostat"

giejay commented 5 years ago

I had the same issue, what worked for me was setting a nickname: room and then saying set the room to 22

JurikRistjouw commented 5 years ago

I am trying to rename the device, but getting some trouble deleting the old device from device list in gbridge and refreshing. Will keep trying

giejay commented 5 years ago

Ah, I was not very clear, I renamed the device in google home, under devices. You can set a nickname over there

JurikRistjouw commented 5 years ago

ah right, thanx! I will try that.

JurikRistjouw commented 5 years ago

I am still having the same issue, even after nicknaming in google. Mode is not supported on the "nickname". (the other stuff works brilliant! Thanx)

giejay commented 5 years ago

When double checking, I saw that only the setpoint trait was added by the plugin. I fixed that with the latest commit and Im now able to set my temperature without any nickname tricks. Can you try again by pulling and clicking update in the hardware section? Make sure to remove the device first from gBridge device page or give it a different name in Domoticz (description)

JurikRistjouw commented 5 years ago

I had to delete the device 2 times (maybe google cache), but after that pulled and "clicked update on domoticz". Device appeared in gBrigde with more traits. mode, setpoint and ambient. It works now without a nickname. I can even say set the room to x degrees, and it "finds" the thermostat.

JurikRistjouw commented 5 years ago

hmm Saying: "lower the living room temperature by 1 degree" -> "that mode isn't suported for the "device name".... but maybe that is a feature request ;)

edit: when saying: what is the current temperature in the room, or device, I get: unable to reach device name...

giejay commented 5 years ago

For the first one: you have to say: lower/increase the temperature in the 'devicename' by 1 (degrees). Have no idea why google didn't make the other one work. Then you will see that Domoticz tries to set the temperature to minus 1/plus 1, thats where the non implemented part comes:) Thankfully I could make a relative small change to also get that working, I'm testing that now on my test environment and will push it this afternoon.

The second one, I'm not sure about. That has no direct relation to this plugin so that seems to be a gBridge issue/Google issue. I'm also not able to get the temperature in the room...

Maybe @peterkappelt can help us?

giejay commented 5 years ago

Just pushed the change, can you try again?

JurikRistjouw commented 5 years ago

I will try again.

JurikRistjouw commented 5 years ago

no luck as of yet. that mode isn't supported on "device"

giejay commented 5 years ago

Very weird, this is my flow:

No idea why that wouldn't work for you

JurikRistjouw commented 5 years ago

i am not sure if it is a cache issue with google or gbridge. Somehow i am unable to properly delete a device (the thermostat) from gbridge to re-add it. Although it says delete succesfull, after a fresh of the page, the device is back. Not sure if this is causing the issue. I restarted domoticz after a pull to make sure. and synced the devices twice.

giejay commented 5 years ago

I had the same issue when readding a device, it kept quering domoticz with the old id so domoticz couldn't find it. After a couple of hours it started sending the new device id so I think it's a cache issue on google side

JurikRistjouw commented 5 years ago

ok, let's see how it behaves tomorrow.

JurikRistjouw commented 5 years ago

still the same :-( i also see no ambient temperature (which makes sense in a way, because it is only a setpoint, but I also don't see the setpoint returned)) Not sure how to assist.

peterkappelt commented 5 years ago

I'd be happy to help.

i am not sure if it is a cache issue with google or gbridge. Somehow i am unable to properly delete a device (the thermostat) from gbridge to re-add it. Although it says delete succesfull, after a fresh of the page, the device is back. Not sure if this is causing the issue. I restarted domoticz after a pull to make sure. and synced the devices twice.

Where are you unable to delete a device? In the gBridge dashboard, in the Google home app or with the Domoticz plugin?

The ambient temperature is never shown in the Google home app, you can only get it by querying. It is "Hey Google, what's the temperature in here?" or "Hey Google, wie warm ist hier?" (in German).

For the issue with devices not syncing properly: There is a command: "Hey Google, synchronisiere meine Geräte"/ "Hey Google, synchronize my devices". It seemed to accelerate the Google syncing a bit.

edit: when saying: what is the current temperature in the room, or device, I get: unable to reach device name...

Could you please give me your gBridge user id and try to reproduce this issue with creating the device in the gBridge dashboard and manually sending the MQTT messages for it?

JurikRistjouw commented 5 years ago

I was unable to delete the device from the gbridge device page. It says delete succesfull, but it keeps returning. But, when deleted, it reappears as a new device in google. Then I readd it to my room.

I can understand that, the ambient temp is not displayed in the setpoint device. Only the setpoint could be read, but that is not the case. In my case a remeha iSense controlled through open therm gateway, the device is only setpoint, not ambient also. There is a sensor for the ambient, but not sure how to match them up so google and or gbridge will understand.

I have tried "sync my devices" twice... a few times now. Also pushed from the hardware tab in domoticz, restarted domoticz and waited. Results are the same.

my id is uniform one six three (hope you get that)

Have tried to reproduce the issue just after posting, not sure how to manually send an mqtt message tho...

peterkappelt commented 5 years ago

The issue with devices reappearing seems to be caused from this plugin. I've checked the logs, a new device seemed to be added via the API. I'd have to look into this plugin, I think I can do it next week.

The problem that Google says "unable to reach device" should actually never happen. However, I'm not able to find anything suspicious in the logs. I can't reproduce it for myself, so debugging is hard.

The process for manually testing would look like that:

@giejay Could you reproduce the problem that the device is not reachable anymore?

giejay commented 5 years ago

I am able to reproduce the issue regarding, what's the temperature in here. Google responds with: Im not sure which device you would like to control.

Regarding adding of devices, its true that after you say: sync my devices, this plugin will add devices from domoticz to gBridge, so that probably explains why the device can't be removed. Disable the plugin in the hardware as Peter mentioned.

JurikRistjouw commented 5 years ago

I will try to remove the device as mentioned with the plugin disabled and readd it.

@peterkappelt It is able to reach the device, but it when asking the current temp it responds with: that mode isn't supported for "device name" or device isn't available right now. When raising the temp it responds with: that mode isn't supported on "device name" When setting the thermostat, it responds with: sure, setting the "device name" to xx.x degrees.

I will mention again, that only one thermostat is added to gbridge, not an ambient temperature sensor. Hence it cannot display or return the current temperature, only the setpoint. I could add the ambient sensor and give it the same name?? would that work?

JurikRistjouw commented 5 years ago

Seems that a temp sensor isn't supported at this time. This was in the logs

2018-12-21 18:08:49.475 Error: (kapelt gBridge) No gBridge adapter found for device: {'Description': 'gBridge:Living Room Thermostat', 'Data': '19.2 C', 'XOffset': '0', 'PlanIDs': [4, 10], 'HardwareID': 8, 'BatteryLevel': 255, 'AddjMulti': 1.0, 'HardwareTypeVal': 20, 'HaveTimeout': False, 'Name': 'otgw Room Temperature', 'YOffset': '0', 'Temp': 19.2, 'Timers': 'false', 'SubType': 'LaCrosse TX3', 'HardwareType': 'OpenTherm Gateway with LAN interface', 'trend': 1, 'idx': '105', 'AddjMulti2': 1.0, 'HardwareName': 'OpenTherm', 'SignalLevel': '-', 'Unit': 8, 'Type': 'Temp', 'Used': 1, 'AddjValue2': 0.0, 'PlanID': '4', 'Notifications': 'false', 'LastUpdate': '2018-12-21 18:08:28', 'TypeImg': 'temperature', 'ShowNotifications': True, 'CustomImage': 0, 'Protected': False, 'Favorite': 1, 'AddjValue': 0.0, 'ID': '0008'}

WARNING: when giving the same description for both sensor and thermostat; the second device isn't pushed anymore.. I could not find the thermostat in gbridge. I removed the same description from the sensor which wasn't supported, and it came back instantly in gbridge.

will test further

giejay commented 5 years ago

Correct, only SetPoint devices are supported for now.

JurikRistjouw commented 5 years ago

ok, clear.

I've come to allmost the same conclusion. Only one thermostat is available and visible in gbridge and google home.

When asking the temperature i get a different response: I am sorry, I am not sure which device you want to control

cannot raise or lower the setpoint, the response is: That mode isn't available for two thermostats.

I can set the temperature, but the response is: Sure, setting the "device name" to xx.x degrees. That mode isn't available for "device"

giejay commented 5 years ago

Can you try readding the device under a different name so we are sure that it's not a google cache issue. What is your GH language? English or German?

JurikRistjouw commented 5 years ago

I will try relinking google regarding the other issue. i guess that should take care of the cache issue? I will add the the thermostat with a different name (currently called living room thermostat). My GH language is English and Dutch.

JurikRistjouw commented 5 years ago

after relinking and adding devices.

asking: lower the temperature on x-> that mode isn't supported for the x asking: set the x temp to xx.x degrees -> you got it, setting the x to xx.x degrees asking: what is the temperature in the x -> I am sorry, I am not sure which device you want me to control

hope this helps

giejay commented 5 years ago

Some development at my side. My temperature setpoint device is called 'Room'. Previously when I asked, whats the temperature in the room, it returned with: 'I am sorry, I am not sure which device you want me to control', just like you. I noticed I had two thermostats in my GH devices (one was a test from my dev machine), I removed that one and now I'm getting: The room is off and its currently zero degrees.

When I go the thermostat in the Google Home app, it states that the ambient temperature is 0 and the device is off, so that seems to make some sense. @peterkappelt Should the plugin do something with query requests (next to commands)? All the data is cached in redis right? So when I say, set the temperature to 22, it saves that in the Redis DB and that cached value is returned when Google queries gBridge, right?

JurikRistjouw commented 5 years ago

I still have the issue with: i am not sure which device you like me to control, afaik only one thermostat is in gbrigde.

when you use cached values, will it pick up a manual setpoint alteration (by hand)? Domoticz will pick that up, but is that also updated to Redis DB from gbridge?

giejay commented 5 years ago

No, thats something that still needs to be implemented, I just don't know how to listen to device changes from my plugin, the only thing I can do is just publish the current state every x minutes/seconds but except for the temperate, which does not work anyway, I don't see the need yet.

giejay commented 5 years ago

I just tested it with a light, asking whether it was on, right after I asked google to turn it on. Unfortunately, it says the device is off so it doesn't seem to be only thermostats which dont work

JurikRistjouw commented 5 years ago

I have the same conclusion, asking if the lights are on in room x it names the 2 lights only (good) and tells me they are off. Right after that it says, unable to reach 6 lights.... (i guess cache issue for the numbers)

JurikRistjouw commented 5 years ago

update: it is definitly cache related somewhere. When i ask now: "set the temperature in the living room to x degrees" it responds: "sure, setting the living heating (new name) to x degrees" "Unable to reach living room thermostat (previous name"

also, the count in the attic is trippled somehow...

please advice how to solve

giejay commented 5 years ago

I'm afraid I can't really help you regarding cache issues, I have the same problem, if I say turn off the outside shutter, it says, sure, turning off 2 things. I guess we will just have to wait it out or something

JurikRistjouw commented 5 years ago

isn't there any way to reset google's cache? maybe @peterkappelt knows a trick?

JurikRistjouw commented 5 years ago

https://support.google.com/googlehome/answer/7073477?hl=en

maybe that could help?

peterkappelt commented 5 years ago

Well, I've got some more time now, since the subscription project is done. Let me tell you, providing and preparing SaaS-products is harder than it seems at a first glance...

However, I'm going to take a day off (tomorrow) and then I'll have a deeper look into this issue, trying to reproduce everything. I expect it to be a combination of a small bug in gBridge, general issues with Google Assistant and a possible misunderstanding about the functionality.

Merry christmas everyone!

JurikRistjouw commented 5 years ago

I can imagine SaaS is hard. Production is something else compared to hobby. Thank you for taking the time to dig into it deeper. I couldn't agree more with your conclusion!

Merry Christmas!

peterkappelt commented 5 years ago

I can imagine SaaS is hard. Production is something else compared to hobby.

Yeah... Actually I'm doing electrical engineering for a living - that is somehow completely different.

I did some experiments this evening. Apparently Google uses different APIs for smart home providers being available to the public (hosted service) and private ones (my development server/ self hosted setups), hence I couldn't reproduce most of your issues on my development system. I tried it on the hosted product - et voilà: I could see the most problems.

As it seems, my assumption was right. There was a small bug in a gBridge component, I fixed it just now. Possibly, the Google caching issue doesn't appear anymore with the gBridge problem bein solved.

And there is a misconception ;). I'm going to write about it tomorrow...

giejay commented 5 years ago

I'm very curious what the fix could be, where did you apply it? I see the latest commit is 4 days ago so not in code?

peterkappelt commented 5 years ago

Well, first about the misconception.

Once you say an Execute-Command to Google (Set x to ..., Turn z on/ off, ...), this value just gets published to the matching MQTT action topic (topics without set appended). Nothing is set in the redis cache for that case.

When you publish something to an MQTT status topic (topics with set appended), this value is indeed stored in the redis cache. Once you say a query-command (Is x turned on?), this cached data gets transfered to Google.

These are two completely separated data paths. In my opinion, in a theoretical and abstract point of view, this is the right way to do for any event driven smart home software. When you ask Google to turn a device on, that doesn't necessarily mean that the device gets turned on - it could be offline, blocked by a fixed timing schedule, in some sort of manual control mode, etc. When you use the described way, you just need to follow a plain structure. If data is received on an action topic, (try) to set the device to that. Everytime a parameter/ setting of your device changes, report that change to the matching status topic, no matter where that change originated from.

When no data is cached (via publishing to the status topics), gBridge uses default values: mode is "off", temperature setpoint and ambient temperature are both "0.0". However, Google reacts strangely to questions about the thermostat if not all parameters are set different from the default values.

Long story short: In order for this to work properly, you need to report some data back to the status topic. The prefered way would be to set up some sort of event listener for the controlled devices, that sends the current data to this topic once something changes for this device.

The easiest way would be to just send back the data to status topic, right at the moment when you receive something on the action topic. Just send some data to the status topic of mode, ambient temperature and setpoint. I expect it to work then.

peterkappelt commented 5 years ago

So, now for the bug of gBridge: I’ve written that once data is sent on the status topic, it gets cached and sent to Google once a query is said. However, if publishing your app publicly, Google requires you to implement the “Report State” feature aside from that (https://developers.google.com/actions/smarthome/report-state). When we receive something on the status topic, we also need to notify Google proactively about the new device states for that user (besides from storing it in the cache for further queries). This part of gBridge is not publicly available, since it is not required for self-hosted setups. In self-hosted setups, Google just queries the cache of the gBridge instance. In the public version, Google wants to keep its own cache. The problem was in this part, it happened under certain load conditions. When two different users sent data to a status topic at the same time (in combination with high system load), it was possible that their data was mixed up. Sometimes, the device states for user A that were sent to Google contained device states from user B. This is no security breach, since the Google API always rejected those invalid records – but with an undocumented error code, that wasn’t catched by the gBridge app. The problem of mixing data were two asynchronous node.js functions, influencing each other. I fixed the problem by replacing promise-/ callback-based functions with the newer await/ async constructs; while adding more code to catch unexpected error codes.

giejay commented 5 years ago

Thanks for the very detailed information! I will try to add support for pushing changes also to the status topics, once a device is (successfully) updated through gBridge, and also when it's updated though Domoticz (app).