-
This plugin was updated by @vosmont to run under openLuup (and possibly UI7.)
@DesT recently asked for a slight addition to its functionality, so I'm adding this thread to discuss the changes.
-
@toggledbits Hi Patrick. I had my internet go down for about 12 hours the other day, and that experience encouraged me to work on getting my HA off the cloud to the extent that I can. I have not converted my Veras to local devices yet, though after the next VeraPlus stable firmware release, I will probably run your scripts to localize the device as I don't see Ezlo surviving to maintain Vera firmware.
My question concerns the icons in your plugins. While attempting to mod a reactor sensor during the outage, I could not really do anything (without a sense of risk anyway) as the icons used are pulled from your website. Many Vera plugins operate this way--no doubt to save space on the vera, and my inclination was to manually start downloading what I needed when the outage was over. I run everything on openLuup and space is not an issue. It occurred to me that localizing a plugin could be a button push somewhere in the plugin UI where one could auto download any needed icons and the plugin would recognize the local copy first, before trying the cloud.
Could this be a possible enhancement to your plugins? I don't really have a technical grasp of whether this would be workable or not.
-
Feedback / solutions with openLuup's built-in Shelly bridge.
-
Feedback / solutions for openLuup's built-in Tasmota MQTT bridge.
-
Am I losing it or did there used to be a sort either alphabetically or numerically option on devices in AltUI?
Seems to not be there there?
TIA
C
-
So, Amazon recently released the ability to execute spoken commands.
dbochicchio/VeraAlexa: Alexa plug-in for Vera and openLuup. (github.com)
Using my plug-in, you could just do something like this:
luup.call_action("urn:bochicchio-com:serviceId:VeraAlexa1", "RunCommand", {Command="-e textcommand:'Alexa, I’m leaving' -d 'Bedroom'"}, 666)Or any spoken command that's not directly accesible via routines. Something like
"Play music everywhere"
"TV volume to 32"
"Pause TV"and much more 🙂
Give it a try!
-
Latest Vera Ecobee Plugin:
rafale77/vera-ecobee rafale77/vera-ecobeeVera Plugin for ecobee Thermostat. Contribute to rafale77/vera-ecobee development by creating an account on GitHub.
-
I've got myself a nice Ecovacs Deebot 950, because one of the Roombas is getting really old (12 years and still going strong). It's my first one connected to WiFi, since the others are legacy. I've found a nice mqtt library and it's already pushing to my broker in real time, but I'm wondering if there's a generic device template and/or service, otherwise I'll start building one and I'll try to keep it as much generic as possible.
-
The plugin has been updated to ver 0.56 which improves the RF learning procedure. It also recognises some of the newer RM4 devices (thanks Bruce Lacey).
Existing uses just need to upload the "L_BroadLink_Mk2_1.lua" file.
RF learning has been improved but is never particularly reliable. You can invoke testing by executing this code in the Lua Test box:
local DeviceID = the_id_of_the_IR_child_device luup.call_action('urn:a-lurker-com:serviceId:IrTransmitter1', 'LearnRFCode', {}, DeviceID) return trueRunning the code illuminates the LED on the BroadLink device. If you do nothing at this point, the learning times out after about 24 seconds and the result is "No RF code was learnt".
While in the learning mode, tap the remote button to be learnt, every 2/3 of a second or so. If the LED goes out (typically after about say 5 seconds) some result was learnt.
The result can be found in the parent device by looking at the variable "LearntRFCode". However, it is far easier to look at the log file, which logs the process as it proceeds and also the result. You need to learn a few results to try and determine if the results are at all consistent.
-
Sharing what I believe is a great way to add support to devices that used to work but since existing plugin haven't been maintain by the original authors (or any other developer in the community) have stopped working as they've abandon or moved to other platform...
Homebridge has a large and very active community and I think this type of plugin will a good way to benefit from it.
It will bring any device that have been configured in homebridge into openluup.
Currently it support, thermostat (Nest and others), Switches (Specially MyQ), Dimmers, Switches, Motion Sensors, Door Lock (Open/close) Support to other type of device can easily be added.
Homebridge2Openluup
upload the files to /you_openluup_directory/files/ create a new device with D_Homebridge2openluup1.xml
Installation:Screen Shot 2021-03-14 at 12.55.29 PM.png
Set your hombredige IP, username, password to the deivce's attributesScreen Shot 2021-03-14 at 12.57.00 PM.png
Capture the uuid of the device you would like to bring from Homebridge into openluup by looking at your openluup logs when startingScreen Shot 2021-03-14 at 1.00.53 PM.png
based on the device type, set DeviceList VariableScreen Shot 2021-03-14 at 1.02.51 PM.png
T for thermostat
D for dimmers
S for switches
G for garage doors
L for Locks
A for motion sensorsand build a string device type are delimited by a ; (semicolong) and device's uui by a , (comma) like this:
T:homebridge_thermostat1_uuid,homebridge_thermostat2_uuid;D:homebridge_dimmer1_uuid,homebridge_dimmer2_uuid etcThis still in beta, would love to add async next and support to shades and other sensors.
-
I've made some mods to Futzle's upnp event proxy and placed it in the AltApp store (with her permission). ie it's here in GitHub.
Now it seems some people say it works with openLuup already. However the version released by Futzle required two things in order to function:
the file L_UPnPProxy1.lua was expected to be compressed, as it would be on a Vera eg: L_UPnPProxy1.lua.lzo
the hardware needs to be running OpenWrt; ie as per Vera does.
I modified the code to fix point 1) (see the script below) but I would like to see point 2) resolved, so a RasPi can be used. That is modify the script to allow a deamon to be run on a RasPi without fiddling around with say "/etc/rc.local".
So has any one got the proxy going on any hardware that is NOT using OpenWrt ? I'm unsure how to do it.
Basically this script and/or the script it includes needs to be modified or even merged to suit. You'll note that after the shebang, it requires the file "etc/rc.common" (reproduced further below). The latter appears to be some sort of template file that is overriden as required by the first script. It cites "$IPKG_INSTROOT", whatever that is. However it may be possible to make use of it somehow on a RasPi?
#!/bin/sh /etc/rc.common # Copyright (C) 2007 OpenWrt.org START=80 PID_FILE=/var/run/upnp-event-proxy.pid PROXY_DAEMON=/tmp/upnp-event-proxy.lua start() { if [ -f "$PID_FILE" ]; then # May already be running. PID=$(cat "$PID_FILE") if [ -d "/proc/$PID" ]; then COMMAND=$(readlink "/proc/$PID/exe") if [ "$COMMAND" = "/usr/bin/lua" ]; then echo "Daemon is already running" return 1 fi fi fi # openLuup: Look for the uncompressed proxy daemon Lua source. if [ -f /etc/cmh-ludl/L_UPnPProxyDaemon.lua ]; then PROXY_DAEMON_UC=/etc/cmh-ludl/L_UPnPProxyDaemon.lua elif [ -f /etc/cmh-ludl/files/L_UPnPProxyDaemon.lua ]; then PROXY_DAEMON_UC=/etc/cmh-ludl/files/L_UPnPProxyDaemon.lua # Vera 3: Else look for the compressed proxy daemon Lua source. elif [ -f /etc/cmh-ludl/L_UPnPProxyDaemon.lua.lzo ]; then PROXY_DAEMON_LZO=/etc/cmh-ludl/L_UPnPProxyDaemon.lua.lzo elif [ -f /etc/cmh-lu/L_UPnPProxyDaemon.lua.lzo ]; then PROXY_DAEMON_LZO=/etc/cmh-lu/L_UPnPProxyDaemon.lua.lzo fi if [ -n "$PROXY_DAEMON_UC" ]; then cp "$PROXY_DAEMON_UC" "$PROXY_DAEMON" elif [ -n "$PROXY_DAEMON_LZO" ]; then /usr/bin/pluto-lzo d "$PROXY_DAEMON_LZO" "$PROXY_DAEMON" fi # Close file descriptors. for fd in /proc/self/fd/*; do fd=${fd##*/} case $fd in 0|1|2) ;; *) eval "exec $fd<&-" esac done # Run daemon. /usr/bin/lua "$PROXY_DAEMON" </dev/null >/dev/null 2>&1 & echo "$!" > "$PID_FILE" } stop() { if [ -f "$PID_FILE" ]; then PID=$(cat "$PID_FILE") if [ -d "/proc/$PID" ]; then COMMAND=$(readlink "/proc/$PID/exe") if [ "$COMMAND" = "/usr/bin/lua" ]; then /bin/kill -KILL "$PID" && /bin/rm "$PID_FILE" return 0 fi fi fi echo "Daemon is not running" return 1 }And here is "etc/rc.common" as found in OpenWrt initscripts. Note the command actions it implements - in particular disable & enable, which set up Sxxy (start) & Kxxy (stop) files in the directory "etc/rc.d", which is not found in the RasPi directory structure:
#!/bin/sh # Copyright (C) 2006-2009 OpenWrt.org . $IPKG_INSTROOT/etc/functions.sh initscript=$1 action=${2:-help} shift 2 start() { return 0 } stop() { return 0 } reload() { return 1 } restart() { trap '' TERM stop "$@" start "$@" } boot() { start "$@" } shutdown() { stop } disable() { name="$(basename "${initscript}")" rm -f "$IPKG_INSTROOT"/etc/rc.d/S??$name rm -f "$IPKG_INSTROOT"/etc/rc.d/K??$name } enable() { name="$(basename "${initscript}")" disable [ "$START" ] && ln -s "../init.d/$name" "$IPKG_INSTROOT/etc/rc.d/S${START}${name##S[0-9][0-9]}" [ "$STOP" ] && ln -s "../init.d/$name" "$IPKG_INSTROOT/etc/rc.d/K${STOP}${name##K[0-9][0-9]}" } enabled() { name="$(basename "${initscript}")" [ -x "$IPKG_INSTROOT/etc/rc.d/S${START}${name##S[0-9][0-9]}" ] } depends() { return 0 } help() { cat <<EOF Syntax: $initscript [command] Available commands: start Start the service stop Stop the service restart Restart the service reload Reload configuration files (or restart if that fails) enable Enable service autostart disable Disable service autostart $EXTRA_HELP EOF } . "$initscript" ALL_COMMANDS="start stop reload restart boot shutdown enable disable enabled depends ${EXTRA_COMMANDS}" list_contains ALL_COMMANDS "$action" || action=help [ "$action" = "reload" ] && action='eval reload "$@" || restart "$@" && :' $action "$@" -
Not quite a plugin but just the addition of a barometer device to be used for various integrations (Domoticz or Home Assistant)
Intructions:
Drop the content of this zip file in a folder openLuup has access to (I put mine into the cmh-ludl/files to pretend these were downloaded from a vera)
then create a device and use D_BarometerSensor1.xml as the device file and I_GenericSensor1.xml for the execution file or anything else actually depending on what your integration is. -
I am looking at making openLuup to act as an MQTT client for a variety of applications. I may write a plugin for it myself based on either of these two libraries:
xHasKx/luamqtt xHasKx/luamqtt
luamqtt - Pure-lua MQTT v3.1.1 and v5.0 client. Contribute to xHasKx/luamqtt development by creating an account on GitHub.
Yongke/luamqttc Yongke/luamqttcA lua mqtt client which support MQTT version 3.1.1 - Yongke/luamqttc
Still have to learn the details of how it would work. If people have ideas, feel free to post here!
-
Anyone here that has visualized the location from iphone locator in grafana?
found the "World Map" panel for grafana, but haven't figured out how to make it display yet..
-
Well, I disappeared down a rabbit hole on a different mission and resurfaced with this monstrosity.
What does it do?
It translates button functions for various (certainly not all) IRP protocols to Pronto codes. These can then be sent by a plugin that sends Pronto Codes to IR transmitters - such as the BroadLink Plugin or the GC100 Plugin (or similar).
The IRP protocol "Device", "Subdevice" and "Function" numbers are stored in a json file as buttons for "virtual remotes".
So you could have say three physical IR transmitters and want to command different AV devices (ie TVs, AVR, Xmas tree, etc) in the vicinity of those various IR emitters.
The button codes are far less cumbersome than heaps of pronto codes. You can set up a virtual remote for each AV device in the json file. Each physical emitter can be assigned to any virtual remote. And away you go!
Well - you already have a pile of pronto codes already running just fine? However, as the plugin "manufacturers" pronto codes, you could also use it to scan/search for functions for any AV device you may have. GitHub has an example for Pioneer: SearchForButtonCodes.lua
Find "Device", "Subdevice" and "Function" codes:
Plugin details in:
Install via AltUI:
Version 0.51
Initial release.Version 0.52
Add RC6 format: includes Windows Media Center based items eg Intel NUCs, Xboxes, Kodi, etc -
As another one asked for it on the other forum, I finally created a new plug-in for Telegram notifications: https://github.com/dbochicchio/vera-Telegram/
You can:
send text messages send (still) images send videos (gif or mp4) send silent notificationsI remember @CatmanV2 was searching for something similar (maybe?).
I'm using it to send push notifications to me and my wife, using a group. I have my own code streaming my cameras and sending a video as gif based on certain events (ie motion sensors or door/entryways left open). While this part is not included into the plug-in, if you're able to get a video yourself (by pointing to a URL), you'd good to go. Still images from cams (or, let's say, your favorite weather map, or any video/gif/image on the Interner ot local) are supported as well.
100% compatible with bot Vera and openLuup (where it was developed, anyway).
Feel free to ask questions or suggest new features.
-
Currently there's no beginners guide to installing RFX plugin on OpenLuup without Vera that i could find, so i'd thought i'd make one.
This is made on Debian 10.6 (Buster).
First: Download the files. The thread on the Vera forum is the place to find the newest version (Currently 1.96), but i found it to have several issues in Openluup.
Auto create makes multiple instances of sensors, and I had a couple of "all sensors disappeared" instances!I use 1.41, which works perfectly as long as you can use Type1/Type2/ext/ext2 FW.
Download from this threadOnce you got the files into /cmh-ludl/ you can proceed to create the device in OpenLuup. In devices - click "Create".
2fd93a27-c760-49bd-b984-9443a905837e-image.png
Sometimes its nessecary to move the RFX..Png file to /cmh-ludl/icons/ to get the correct icon in OpenLuup.
Next is to get the RFX up and running, for that you need ser2net. Installation instructions
Ser2net needs to find the USB, and to fint the address, do this:
user@device:~$ cd /dev/serial/by-id/ user@device:/dev/serial/by-id$ ls usb-0658_0200-if00 usb-RFXCOM_RFXtrx433_A118TU8K-if00-port0 user@device:/dev/serial/by-id$this ID can be used in the /etc/ser2net.conf, at the end of the file:
# found in /usr/share/doc/ser2net/examples BANNER:banner:\r\nser2net port \p device \d [\s] (Debian GNU/Linux)\r\n\r\n 2000:telnet:600:/dev/ttyS0:9600 8DATABITS NONE 1STOPBIT banner ... 3001:telnet:600:/dev/ttyS1:19200 8DATABITS NONE 1STOPBIT banner 3485:raw:0:/dev/serial/by-id/usb-RFXCOM_RFXtrx433_A118TU8K-if00-port0:38400 8DATABITS NONE 1STOPBITThe port can be whatever you want (almost), the default in the RFX plugin is 10000
Save and restart ser2net.Back in OpenLuup, go to the "Attributes" tab of the RFX Plugin,and ensure that the IP address is correct:
6391e20b-6f4c-4101-8633-6ee1e01fb905-image.png I'm using a local USB, but this might as well be on a different device on your network.Now, go to the "Variables", and insert the correct port number in "IPPort" variable.
If all goes well, the plugin should be good to go after a Luup Reload!
-
I just published an update to my Virtual Devices Plug-in.
What's new in version 1.5:
support for async HTTP (out of the box on openluup, just download https://github.com/akbooer/openLuup/blob/master/openLuup/http_async.lua and copy with the plug-in files on Vera) experimental support for setpoints management in Virtual Heaters (you know, the device will turn itself off if temperature is reached, and automatically on when temperature is not beyond the setpoint) external device for temperature in Virtual Heaters (just set urn:bochicchio-com:serviceId:VirtualHeater1/TemperatureDevice variable) small fixes, stabilizationGrab your copy from https://github.com/dbochicchio/vera/tree/master/VirtualDevices
As always, 100% local, 100% apps friendly, 100% supported by Alexa (and Google Home, I guess).
Homebridge to Openluup
-
Sharing what I believe is a great way to add support to devices that used to work but since existing plugin haven't been maintain by the original authors (or any other developer in the community) have stopped working as they've abandon or moved to other platform...
Homebridge has a large and very active community and I think this type of plugin will a good way to benefit from it.
It will bring any device that have been configured in homebridge into openluup.
Currently it support, thermostat (Nest and others), Switches (Specially MyQ), Dimmers, Switches, Motion Sensors, Door Lock (Open/close) Support to other type of device can easily be added.
Homebridge2Openluup
Installation:- upload the files to /you_openluup_directory/files/
- create a new device with D_Homebridge2openluup1.xml
- Set your hombredige IP, username, password to the deivce's attributes
- Capture the uuid of the device you would like to bring from Homebridge into openluup by looking at your openluup logs when starting
- based on the device type, set DeviceList Variable
T for thermostat
D for dimmers
S for switches
G for garage doors
L for Locks
A for motion sensorsand build a string device type are delimited by a ; (semicolong) and device's uui by a , (comma) like this:
T:homebridge_thermostat1_uuid,homebridge_thermostat2_uuid;D:homebridge_dimmer1_uuid,homebridge_dimmer2_uuid etcThis still in beta, would love to add async next and support to shades and other sensors.
-
Hi Ron, thanks for that.
Not a HomeBridge user myself (yet) but it might be nice to have a version of the above information in the GitHub README file.
Hope all's well (as it can be!)
AK
-
I will add my Thanks as well. This is a great addition! I use Homekit in the other direction but I can definitely see use cases for this.
-
thanks @akbooer . I'll be adding the installation instructions to the readme file... By the way, this plugin also works for ecobee thermostat, the native ecobee lua plugin by @rafale77 works ok when there is only one thermostat in the ecobee account but when more than one, ecobee server keeps deauthorizing the plugin...
@rafale77 I also use homebridge the other way (openluup to homebridge) and is great.
I'm currently using it for:
- Nest thermostats with google accounts.
- Ecobee accounts with multiple thermostats
- AUX Mini split with built-in wifi modules
Planning on adding control for AppleTV , Ring devices, Doorbird motion detection and many more...
It will allow us to finally include many of the popular cloud based devices that own into the openluup environment...
Something really cool about homebridge is that the manual and basic automation can be done from within homekit by the end-user, but deeper logic can be done from within openluup. Thinking about bringing node-red into the mix also... anyhow... I hope it can be useful for everyone here...
-
Hi ronluna
Great to see more stuff supporting openLuup and the like. If you feel like adding the plugin to the Alt App Store; I can add it to the list of available plugins:
-
A bit farfetched at the moment but I just had a brainfart that I could bridge my Home Assistant components to homekit and then fetch them back into openLuup using this plugin... pretty awesome.
-
My thermostats show values in Fahrenheit, is there a way to change to Celsius?
I found this in the log but doesn't seem to have any effect.homebridge2openluup debug: Engine Global Temperature Unit = C -
@crille I'll add support to the upcoming update.
-
Just added some fixes for Celsius @crille Please test the latest update from the github repo.
-
@ronluna Yes, it's displayed in Celsius now, thank you.
-
@ronluna I cannot change setpoint though.
Homebridge:[string "L_Homebridge2openluup1.lua"]:83: attempt to compare number with string -
@crille pushed new fix for celsius. the plugin is now available on the altappstore.
-
@a-lurker done!
-
@ronluna I reinstalled the plugin from altappstore but still can't change setpoint. It's sending the wrong characteristicType
2021-03-19 08:47:29.288 luup_log:17: homebridge2openluup debug: Homebridge Put device VALUE = 23 2021-03-19 08:47:29.288 luup_log:17: homebridge2openluup debug: request_body for everything else = {"characteristicType":"HeatingThresholdTemperature","value":"23"} 2021-03-19 08:47:29.288 luup_log:17: homebridge2openluup debug: PUT Auth = Bearer XXXXXXXXXX 2021-03-19 08:47:29.288 luup_log:17: homebridge2openluup debug: PUT Request Body = {"characteristicType":"HeatingThresholdTemperature","value":"23"} 2021-03-19 08:47:29.288 luup_log:17: homebridge2openluup debug: PUT Request Length = 65 2021-03-19 08:47:29.303 luup_log:17: homebridge2openluup debug: URL request result: r = 1 2021-03-19 08:47:29.303 luup_log:17: homebridge2openluup debug: URL request result: c = 400 2021-03-19 08:47:29.303 luup_log:17: homebridge2openluup debug: URL request result: h = table: 0x55b66e8b2910 2021-03-19 08:47:29.303 luup_log:17: homebridge2openluup debug: PUT Access Token = XXXXXXXXXX 2021-03-19 08:47:29.303 luup_log:17: homebridge2openluup debug: response_body PUT 1 = {"statusCode":400,"message":"Invalid characteristicType. Valid types are: 'TargetHeatingCoolingState', 'TargetTemperature', 'TemperatureDisplayUnits', 'RotationSpeed', 'TargetHorizontalTiltAngle', 'TargetVerticalTiltAngle'.","error":"Bad Request"} 2021-03-19 08:47:29.303 luup_log:17: homebridge2openluup debug: HTTP 400 Bad Request: JSON parse error -
This post is deleted! -
@crille I thought there were only two type of temperature controller (Thermostat and HeaterCooler) in homebridge/homekit but apparently I'm wrong. I also thought homebridge/homekit (depending on the device type) would force device to share the same characteristicType ... Seems like I was wrong again... so depending on the plugin being used on homebridge the author may very well define the characteristicType somewhat differently to other plugin-ins...
What kind of thermostat is configured on your homebridge setup? Brand / model . Can you please share the json response when the plug-in is updating the device’s values.. similar to this:
2021-03-21 07:24:20.861 luup_log:83: homebridge2openluup debug: concat_response_body 1 = {"aid":339,"iid":8,"uuid":"0000004A-0000-1000-8000-0026BB765291","type":"Thermostat","humanType":"Thermostat","serviceName":"My ecobee","serviceCharacteristics":[{"aid":339,"iid":10,"uuid":"0000000F-0000-1000-8000-0026BB765291","type":"CurrentHeatingCoolingState","serviceType":"Thermostat","serviceName":"My ecobee","description":"Current Heating Cooling State","value":0,"format":"uint8","perms":["ev","pr"],"maxValue":2,"minValue":0,"minStep":1,"canRead":true,"canWrite":false,"ev":true},{"aid":339,"iid":11,"uuid":"00000033-0000-1000-8000-0026BB765291","type":"TargetHeatingCoolingState","serviceType":"Thermostat","serviceName":"My ecobee","description":"Target Heating Cooling State","value":0,"format":"uint8","perms":["ev","pr","pw"],"maxValue":3,"minValue":0,"minStep":1,"canRead":true,"canWrite":true,"ev":true},{"aid":339,"iid":12,"uuid":"00000011-0000-1000-8000-0026BB765291","type":"CurrentTemperature","serviceType":"Thermostat","serviceName":"My ecobee","description":"Current Temperature","value":24.3667,"format":"float","perms":["ev","pr"],"unit":"celsius","maxValue":37.77777777777778,"minValue":-73.33333333333333,"minStep":0.1,"canRead":true,"canWrite":false,"ev":true},{"aid":339,"iid":13,"uuid":"00000035-0000-1000-8000-0026BB765291","type":"TargetTemperature","serviceType":"Thermostat","serviceName":"My ecobee","description":"Target Temperature","value":23.8556,"format":"float","perms":["ev","pr","pw"],"unit":"celsius","maxValue":26.666666666666664,"minValue":15.555555555555555,"minStep":0.1,"canRead":true,"canWrite":true,"ev":true},{"aid":339,"iid":14,"uuid":"00000036-0000-1000-8000-0026BB765291","type":"TemperatureDisplayUnits","serviceType":"Thermostat","serviceName":"My ecobee","description":"Temperature Display Units","value":1,"format":"uint8","perms":["ev","pr","pw"],"maxValue":1,"minValue":0,"minStep":1,"canRead":true,"canWrite":true,"ev":true}],"accessoryInformation":{"Manufacturer":"ecobee","Model":"nikeSmart","Name":"My ecobee","Serial Number":"Vera ID: 173","Firmware Revision":"0.8.3-beta.12"},"values":{"CurrentHeatingCoolingState":0,"TargetHeatingCoolingState":0,"CurrentTemperature":24.3667,"TargetTemperature":23.8556,"TemperatureDisplayUnits":1},"instance":{"name":"homebridge","username":"0E:10:83:81:C6:A5","ipAddress":"10.1.11.21","port":51706,"services":[],"connectionFailedCount":0},"uniqueId":"240d0198fc8289b3b5a77315b7e4ec132096ddbd6e6beb5e4c174a6a84908e8d"} -
@ronluna I thought so as well. That’s why I thought any device configured as a thermostat in homebridge would have the same characteristics and your plugin would support it.
My “thermostat” is another homebridge plugin for MELCloud (Mitsubishi cloud for my WiFi connected inverters).Here is the json response:
luup_log:17: homebridge2openluup debug: concat_response_body 1 = {"aid":60,"iid":8,"uuid":"0000004A-0000-1000-8000-0026BB765291","type":"Thermostat","humanType":"Thermostat","serviceName":"Övervåningen","serviceCharacteristics":[{"aid":60,"iid":10,"uuid":"0000000F-0000-1000-8000-0026BB765291","type":"CurrentHeatingCoolingState","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Current Heating Cooling State","value":1,"format":"uint8","perms":["pr","ev"],"maxValue":2,"minValue":0,"canRead":true,"canWrite":false,"ev":true},{"aid":60,"iid":11,"uuid":"00000033-0000-1000-8000-0026BB765291","type":"TargetHeatingCoolingState","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Target Heating Cooling State","value":1,"format":"uint8","perms":["pr","pw","ev"],"maxValue":3,"minValue":0,"canRead":true,"canWrite":true,"ev":true},{"aid":60,"iid":12,"uuid":"00000011-0000-1000-8000-0026BB765291","type":"CurrentTemperature","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Current Temperature","value":23,"format":"float","perms":["pr","ev"],"unit":"celsius","maxValue":100,"minValue":0,"minStep":0.1,"canRead":true,"canWrite":false,"ev":true},{"aid":60,"iid":13,"uuid":"00000035-0000-1000-8000-0026BB765291","type":"TargetTemperature","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Target Temperature","value":22,"format":"float","perms":["pr","pw","ev"],"unit":"celsius","maxValue":38,"minValue":10,"minStep":0.1,"canRead":true,"canWrite":true,"ev":true},{"aid":60,"iid":14,"uuid":"00000036-0000-1000-8000-0026BB765291","type":"TemperatureDisplayUnits","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Temperature Display Units","value":0,"format":"uint8","perms":["pr","pw","ev"],"maxValue":1,"minValue":0,"canRead":true,"canWrite":true,"ev":true},{"aid":60,"iid":15,"uuid":"00000029-0000-1000-8000-0026BB765291","type":"RotationSpeed","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Rotation Speed","value":60,"format":"float","perms":["pr","pw","ev"],"unit":"percentage","maxValue":100,"minValue":0,"minStep":1,"canRead":true,"canWrite":true,"ev":true},{"aid":60,"iid":16,"uuid":"0000006C-0000-1000-8000-0026BB765291","type":"CurrentHorizontalTiltAngle","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Current Horizontal Tilt Angle","value":0,"format":"int","perms":["pr","ev"],"unit":"arcdegrees","maxValue":90,"minValue":-90,"minStep":1,"canRead":true,"canWrite":false,"ev":true},{"aid":60,"iid":17,"uuid":"0000007B-0000-1000-8000-0026BB765291","type":"TargetHorizontalTiltAngle","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Target Horizontal Tilt Angle","value":0,"format":"int","perms":["pr","pw","ev"],"unit":"arcdegrees","maxValue":90,"minValue":-90,"minStep":1,"canRead":true,"canWrite":true,"ev":true},{"aid":60,"iid":18,"uuid":"0000006E-0000-1000-8000-0026BB765291","type":"CurrentVerticalTiltAngle","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Current Vertical Tilt Angle","value":-45,"format":"int","perms":["pr","ev"],"unit":"arcdegrees","maxValue":90,"minValue":-90,"minStep":1,"canRead":true,"canWrite":false,"ev":true},{"aid":60,"iid":19,"uuid":"0000007D-0000-1000-8000-0026BB765291","type":"TargetVerticalTiltAngle","serviceType":"Thermostat","serviceName":"Övervåningen","description":"Target Vertical Tilt Angle","value":-45,"format":"int","perms":["pr","pw","ev"],"unit":"arcdegrees","maxValue":90,"minValue":-90,"minStep":1,"canRead":true,"canWrite":true,"ev":true}],"accessoryInformation":{"Manufacturer":"Mitsubishi","Model":"Default-Model","Name":"Övervåningen","Serial Number":"1805118279","Firmware Revision":"0.3.4"},"values":{"CurrentHeatingCoolingState":0,"TargetHeatingCoolingState":0,"CurrentTemperature":0,"TargetTemperature":10,"TemperatureDisplayUnits":0,"RotationSpeed":0,"CurrentHorizontalTiltAngle":-90,"TargetHorizontalTiltAngle":-90,"CurrentVerticalTiltAngle":-90,"TargetVerticalTiltAngle":-90},"instance":{"name":"homebridge","username":"CC:22:3D:E3:CE:43","ipAddress":"127.0.0.1","port":51826,"services":[],"connectionFailedCount":0},"uniqueId":"8f37721c51dc9fd6b15aad7024d6a8460038b1ee7e6fb23c732f1abc5bcfb8fd"} -
@crille Please test the latest commit on github.
-
@ronluna Sorry, but it does not work.
I believe the MELCloud plugin only accepts "TargetTemperature" for changing Setpoint
luup_log:17: homebridge2openluup debug: response_body PUT 1 = {"statusCode":400,"message":"Invalid characteristicType. Valid types are: 'TargetHeatingCoolingState', 'TargetTemperature', 'TemperatureDisplayUnits', 'RotationSpeed', 'TargetHorizontalTiltAngle', 'TargetVerticalTiltAngle'.","error":"Bad Request"}and not
luup.variable_set:: 18.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint was: 22 now: 18 #hooks:0This is only if you want to support the MELCloud provisioned thermostat, otherwise do not put to much energy in to it.
For me it would be at great way to control my temperature triggered by house modes since there is no MELCloud plugin for openLuup.
-
@crille said in Homebridge to Openluup:
TargetTemperature
That's characteristicType the plugin is trying to set for your plugin. Can your share what are the Manufacturer, Model and Type variables set to?
