Hi akbooer,
I've an installation with a centralized openluup/DY on Debian 11 where're archived and consolidated several remote openluup/DY on RPI. I'm also using a user-defined (defined with your support) "DataUser.lua" to process metrics and creating different metric names. I've a schema of this configuration but I can't upload on forum.
I'd like to manage outage network connections between remote and centralized system while the remote DY is running and archives data locally.
I see the whisper-fill.py python routine (https://github.com/graphite-project/whisper/blob/master/bin/whisper-fill.py) from Graphite tool. I know that DY/whisper format is different from Graphite/whisper (CSV vs. binary packing), but based on your deep knowledge and experience is it hard to adapt the fill routine to DY/whisper format ?
tnks
donato
Been using zigbee2mqtt and openLuup for sometime now and it is working well.
I attempted to add another Hue switch to-day. It's a newer version of the other ones I have been using so far. They are pretty much identical.
The older ones installed no problem (which is weird), but the new one won't. Looking at the code, it looks this function in L_Zigbee2MQTTBridge.lua:
configure_scene_controller(dno)is not being passed the parameter "dno" when the function is called. The device is created but is incomplete.
Just out of interest how do you pretty print to the log from within say L_Zigbee2MQTTBridge.lua? I tried a few incarnations such a:
local pretty = openLuup.loader.shared_environment.prettybut they all failed.
Originally I was using Futzle's UPnP event proxy plugin on Vera with the Sonos plugin. Worked very well.
On making the move to openLuup, one finds that the proxy can't be used because the proxy daemon start and stop, etc uses a script installed by the plugin that only works on openWRT, as used by Vera.
The Sonos plugin still works without the proxy but it reverts to polling. It becomes a bit on the sluggish side and sometimes doesn't function quite as intended.
I've modified the proxy plugin to install a script that runs as a systemd service. systemd can be found on a lot of contemporary Linux installs, including Raspberry Pis. To make use of; just install the plugin from the AltUI app store and restart the Luup engine a couple of times. The dashboard should indicate "Status: Proxy running".
Note that the service file expects "L_UPnPProxyDaemon.lua" to be located at the typical plugin files location:
/etc/cmh-ludl/After the plugin is installed, the service file should be found in:
/etc/systemd/system/as UPnPProxy.service.
If you use the Sonos plugin, you need to change the variable "UseProxy" to "1" and restart the LuupEngine. In the Sonos parent device, you should see: "Running x zones; proxy detected".
Updated doco here.
Hope it works - YMMV.
Well pretty sure I didn't change or touch anything! I've turned everything on and off again as one might hope. Excepting a total reboot of the Pi3 that's running all my stuff very reliably in openLuup.
It's all been working well for years and now all of sudden 6 second alerts are truncated to about 4 seconds. Occasionally it works as it should. I see this in the log - does it help?
2023-02-20 09:39:06.662 luup_log:0: My Lua ver 0.50 debug: executing scene 63: "Check windows doors" in room: "Watchers" 2023-02-20 09:39:06.663 luup.call_action:: 217.urn:micasaverde-com:serviceId:Sonos1.Alert 2023-02-20 09:39:06.663 luup.call_action:: action will be handled by parent: 214 2023-02-20 09:39:06.663 luup_log:0: My Lua ver 0.50 debug: rest of scene 63 was executed 2023-02-20 09:39:06.663 luup.scenes:: scene 63, Check windows doors, initiated by AltUI 2023-02-20 09:39:06.665 luup_log:214: Sonos: Alert action on device 217 URI "http://redacted:3480/www/sounds/AllClosed.mp3" duration "6" 2023-02-20 09:39:06.758 luup_log:214: Sonos: UPnP_request (Pause, urn:schemas-upnp-org:service:AVTransport:1): status=1 statusMsg=500 result=[<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring>UPnPError</faultstring><detail><UPnPError xmlns="urn:schemas-upnp-org:control-1-0"><errorCode>701</errorCode></UPnPError></detail></s:Fault></s:Body></s:Envelope>] 2023-02-20 09:39:06.759 luup_log:214: stack traceback: ./L_SonosSystem1.lua:265: in function 'error' ./L_SonosUPnP.lua:289: in function <./L_SonosUPnP.lua:169> (tail call): ? ./L_SonosSystem1.lua:3390: in function 'sayOrAlert' ./L_SonosSystem1.lua:3452: in function 'queueAlert' ./L_SonosSystem1.lua:3843: in function <./L_SonosSystem1.lua:3839> (tail call): ? [C]: in function 'pcall' ./openLuup/scheduler.lua:204: in function 'context_switch' ./openLuup/scheduler.lua:366: in function 'dispatch' ./openLuup/scheduler.lua:588: in function 'task_callbacks' ./openLuup/scheduler.lua:699: in function 'start' openLuup/init.lua:354: in main chunk [C]: ? 2023-02-20 09:39:06.888 luup.variable_set:: 214.urn:toggledbits-com:serviceId:SonosSystem1.zoneInfo was: {"zones":{"RINCON_000E58DC7BBE01400":{"Location":"http://redacted3:1400/xml/device_description.xml","Group":"RIN... now: {"zones":{"RINCON_000E58DC7BBE01400":{"Location":"http://redacted3:1400/xml/device_description.xml","Group":"RIN... #hooks:0 2023-02-20 09:39:06.895 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.TransportState was: STOPPED now: TRANSITIONING #hooks:0 2023-02-20 09:39:06.901 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentPlayMode was: SHUFFLE_NOREPEAT now: NORMAL #hooks:0 2023-02-20 09:39:06.913 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentTransportActions was: Set, Stop, Pause, Play, X_DLNA_SeekTime, Next, X_DLNA_SeekTrackNr now: Set, Stop, Pause, Play, X_DLNA_SeekTime, X_DLNA_SeekTrackNr #hooks:0 2023-02-20 09:39:06.921 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.NumberOfTracks was: 10 now: 1 #hooks:0 2023-02-20 09:39:06.922 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.AVTransportURI was: x-rincon-queue:RINCON_000E58DC7BBE01400#0 now: http://redacted:3480/www/sounds/AllClosed.mp3 #hooks:0 2023-02-20 09:39:11.929 luup_log:214: Sonos: UPnP_request() "urn:schemas-upnp-org:service:AVTransport:1"#"GetPositionInfo" action took 5.0073010921478s (long) 2023-02-20 09:39:11.932 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentTrackDuration was: 0:02:22 now: 0:00:00 #hooks:0 2023-02-20 09:39:11.933 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentTrackURI was: x-file-cifs://ELEPHANT1/Multimedia/My%20Music/Music%20JP/The%20Smiths/The%20Queen%20Is%20Dead/08%20Vicar%20in%20a%2... now: http://redacted:3480/www/sounds/AllClosed.mp3 #hooks:0 2023-02-20 09:39:11.934 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentTrackMetaData was: <DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r... now: <DIDL-Lite xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:r... #hooks:0 2023-02-20 09:39:11.936 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentStatus was: Vicar in a Tutu: (The Smiths, The Queen Is Dead) now: AllClosed.mp3 #hooks:0 2023-02-20 09:39:11.937 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentTitle was: Vicar in a Tutu now: AllClosed.mp3 #hooks:0 2023-02-20 09:39:11.937 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentArtist was: The Smiths now: #hooks:0 2023-02-20 09:39:11.938 luup.variable_set:: 217.urn:upnp-org:serviceId:AVTransport.CurrentAlbum was: The Queen Is Dead now: #hooks:0Also see these:
2023-02-24 16:12:13.576 openLuup.server:: GET /www/sounds/YouRang.mp3 HTTP/1.1 tcp{client}: 0x17e96f0 2023-02-24 16:12:13.579 openLuup.server:: error 'closed' sending 43102 bytes to tcp{client}: 0x17e96f0So any clues?
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.
Hi,
I've installed switchboard plugin from openluup app store but I'm not sure which action to use to create a binary switch. I try "addswitch" action but I see the device only after using the "addchild" action too. is it correct ?
Attached the openluup device screen, the control switchboard and the actions i see.
tnks donato
switchboard_openluup_console.png
Hi @akbooer,
I have an updated version of one of my plugins but I cannot publish it in the ALTApp Store. When I click publish it gets in a sort of loop of Refreshing Token.../Token refreshed. However, I never get to page to refresh the token.
Looking at the browser debug window I see this as the response to http://192.168.178.101:3480/data_request?id=lr_ALTUI_Handler&command=refresh_auth_token
{"error":{"code":400,"message":"Bad Request - invalid_grant","step":"Get access token from refresh token"}}
Running openLuup v21.7.25. Any suggestion?
Cheers Rene
Hi Patrick/AK Booer
I am able to see Reactor expressions in the AltUI UI per the below and the expressions work as they should in my reactor sensors. When an expression changes, the reactor sensor responds accordingly.
javascript.png
However, I cannot see the expressions in luup state variables or the luup logs:
Luup.png
Log.png
I tried reinstalling openLuup (latest development) and when that failed to change the noted behavior, I reinstalled lua5.1. There was also no change. Rebooting the machine also produced no change.
I suspect this is an openLuup issue as I also see nil values for some plugins:
plugin.png
And other plugins are fine:
2022-01-12 20:47:12.027 luup.variable_set:: 63.urn:upnp-micasaverde-com:serviceId:Weather1.CurrentDewPoint was: 32 now: 29.7 #hooks:0 2022-01-12 20:47:12.028 luup.variable_set:: 63.urn:upnp-micasaverde-com:serviceId:Weather1.WindSpeed was: 1.76 now: 2.8 #hooks:0 2022-01-12 20:47:12.028 luup.variable_set:: 63.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 30 now: 27 #hooks:0 2022-01-12 20:47:12.028 luup.variable_set:: 65.urn:micasaverde-com:serviceId:HumiditySensor1.CurrentLevel was: 30 now: 27 #hooks:0 2022-01-12 20:47:12.028 luup.variable_set:: 63.urn:upnp-micasaverde-com:serviceId:Weather1.LastUpdate was: 1642047430 now: 1642049231 #hooks:0Any ideas on how to troubleshoot this.....
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).
This topic has come up before but I haven't seen an answer. Symptom: AltuUI says there is a new update available, so you tell it to do the update but the update does not happen. AltUI remains stuck on it's old version. On other occasions it works OK. So my version is:
AltUI v2.49.2546, © 2019AltUI says this:
a newer version #2551 of ALTUI is available, do you want to upgrade ? add scrollable dialog for long boxes bugfix: clock display on safari remote url update ( @olov ) update jquery and bootstrap versions credential to camera device url ( @rafale77 ) ignore Ezlo hub ( @reneboer)Track through the JavaScript and find that this issues the update command:
function _triggerAltUIUpgrade(newversion,newtracnum) { var url = '?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&Version={1}&TracRev={0}'.format(newversion,newtracnum); return _httpGet(url,{}).always( function() { PageMessage.message(_T("Upgrade Request succeeded, a Luup reload will happen"),"success"); }); };And the url variable equals:
url: "?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&Version=40628&TracRev=2551"All looks good so far. I manually issue the same url complete with my openLuup ip_address in a local browser. Update fails - looks like AltUI is doing as it should:
http://ip_address:3480/data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&Version=40628&TracRev=2551In openLuup I see:
2021-12-06 13:56:14.821 luup_log:3: ALTUI: startupDeferred, called on behalf of device:3 2021-12-06 13:56:14.838 luup.variable_set:: 3.urn:upnp-org:serviceId:altui1.Version was: v2.49 now: v2.49 #hooks:0And then later:
2021-12-06 13:55:58.256 openLuup.server:: GET /data_request?id=action&serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1&action=CreatePlugin&PluginNum=8246&Version=40628&TracRev=2551 HTTP/1.1 tcp{client}: 0x25712a8 2021-12-06 13:55:58.257 luup.call_action:: 0.urn:micasaverde-com:serviceId:HomeAutomationGateway1.CreatePlugin 2021-12-06 13:55:58.259 luup.call_action:: 4.urn:upnp-org:serviceId:AltAppStore1.update_plugin 2021-12-06 13:55:58.260 luup_log:4: AltAppStore : starting <run> phase... 2021-12-06 13:55:58.262 luup_log:4: AltAppStore : downloading amg0/ALTUI [2551] to trash/AltAppStore/ 2021-12-06 13:55:58.262 luup_log:4: AltAppStore : GitHub request: https://api.github.com/repos/amg0/ALTUI/contents?ref=2551 2021-12-06 13:55:58.760 luup_log:4: AltAppStore : GitHub request: https://api.github.com/repos/amg0/ALTUI/contents/blockly?ref=2551 2021-12-06 13:55:59.543 luup_log:4: AltAppStore : getting contents of version: 2551 2021-12-06 13:55:59.544 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine1 was: AltAppStore now: Downloading... #hooks:0 2021-12-06 13:55:59.544 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine2 was: now: Alternate UI #hooks:0 2021-12-06 13:55:59.544 luup_log:4: AltAppStore : scheduling <job> phase... 2021-12-06 13:55:59.544 openLuup.requests:: 2021-12-06 13:55:59.545 openLuup.server:: request completed (148 bytes, 1 chunks, 1288 ms) tcp{client}: 0x25712a8 2021-12-06 13:55:59.554 openLuup.server:: request completed (6233 bytes, 1 chunks, 16442 ms) tcp{client}: 0x255e680 2021-12-06 13:55:59.555 luup_log:4: AltAppStore : ...final <job> phase 2021-12-06 13:55:59.555 luup_log:4: AltAppStore : Total size 0.000 (kB) 2021-12-06 13:55:59.555 luup.variable_set:: 4.urn:upnp-org:serviceId:altui1.DisplayLine2 was: Alternate UI now: Alternate UI 100% #hooks:0 2021-12-06 13:55:59.555 luup_log:4: AltAppStore : updating icons in icons/ ... 2021-12-06 13:55:59.555 luup_log:4: AltAppStore : updating device files in ./ ... 2021-12-06 13:55:59.556 luup_log:4: AltAppStore : ... 0 icon files 2021-12-06 13:55:59.556 luup_log:4: AltAppStore : ... 0 device files 2021-12-06 13:55:59.556 luup_log:4: AltAppStore : Alternate UI update completed 2021-12-06 13:55:59.556 openLuup.luup:: device 4 'Alternate App Store' requesting reload 2021-12-06 13:55:59.556 luup.reload:: saving user_data 2021-12-06 13:56:00.262 openLuup.luup:: exiting with code 42 - after 0.3 hoursAll looks OK. Then I check GitHub. It shows the latest changes to the version 2551. However this page says the latest version is 2550.
So I wondering what's going on. Seems the latest version number is not being picked by the installer? (not sure how it works.) Is it possible for openLuup to log a bit more about the version it's trying to install. As this call returns.
https://api.github.com/repos/amg0/ALTUI/contents?ref=2551 message "No commit found for the ref 2551" documentation_url "https://docs.github.com/v3/repos/contents/"But this works fine:
https://api.github.com/repos/amg0/ALTUI/contents?ref=2550So it looks like AMG0 doesn't always update the repository with whatever is needed to get this to work (I imagine that's easy to forget). But could openLuup send back a fail result to AltUI and AltUI pick that up? Currently it looks like AltUI always assumes everything went OK. Or somehow; could openLuup log and/or notify the user what went wrong?
Hi @toggledbits and others,
Could you help me out with the following use case? I have a z-wave module that doesn't have scene functionality, but I want to trigger a double click action on the switch.
What is the easiest way to do this in reactor? I'm struggling with this and I think I'm thinking too complex at this point.
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
Read about the IRP protocol
Find "Device", "Subdevice" and "Function" codes:
IR database
Plugin details in:
GitHub
Install via AltUI:
Plugins available 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
Panasonic plasma TV json.jpg
Panasonic plasma TV web page.jpg
@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.
openLuup: Tasmota MQTT Bridge
-
@akbooer Yes, I'm starting to see what your up against here. MQTT, because of its flexibility, is not going fit into established serviceiDs. Developing a UI to manage this complexity will take some creative insight.....
Attached is a sample screenshot of the device file. Note the three sensors listed on the left with non-friendly names
And here is the actual device file as displayed in the console:
[{ "ControlURLs":[], "altid":"power_BedroomTV", "category_num":0, "device_file":"D_GenericTasmotaDevice.xml", "device_json":"D_GenericTasmotaDevice.json", "device_type":"GenericTasmotaDevice", "disabled":0, "id":30001, "id_parent":262, "invisible":"0", "ip":"", "local_udn":"uuid:d764c8cc-e932-55c4-478d-7aa05d83f3ea", "mac":"", "manufacturer":"could be anyone", "model":"", "name":"power_BedroomTV", "plugin":"", "room":"35", "states":[{ "id":0, "service":"urn:micasaverde-com:serviceId:HaDevice1", "value":"1620676905", "variable":"LastUpdate" },{ "id":1, "service":"power_BedroomTV", "value":"{\"Time\":\"2021-05-10T21:01:44\",\"Switch1\":\"ON\",\"Switch2\":\"ON\",\"ENERGY\":{\"TotalStartTime\":\"2021-04-04T05:29:11\",\"Total\":0.000,\"Yesterday\":0.000,\"Today\":0.000,\"Period\":0,\"Power\":[0,0],\"ApparentPower\":[0,0],\"ReactivePower\":[0,0],\"Factor\":[0.00,0.00],\"Frequency\":60,\"Voltage\":121,\"Current\":[0.000,0.000]}}", "variable":"tele" },{ "id":2, "service":"LYWSD03eb4f4f", "value":"a4c138eb4f4f", "variable":"mac" },{ "id":3, "service":"LYWSD03eb4f4f", "value":"21.7", "variable":"Temperature" },{ "id":4, "service":"LYWSD03eb4f4f", "value":"62", "variable":"Humidity" },{ "id":5, "service":"LYWSD03eb4f4f", "value":"-74", "variable":"RSSI" },{ "id":6, "service":"LYWSD03eb4f4f", "value":"14.1", "variable":"DewPoint" },{ "id":7, "service":"power_BedroomTV", "value":"2021-05-10T21:01:44", "variable":"Time" },{ "id":8, "service":"LYWSD0338eb2e", "value":"a4c13838eb2e", "variable":"mac" },{ "id":9, "service":"LYWSD0338eb2e", "value":"21.6", "variable":"Temperature" },{ "id":10, "service":"LYWSD0338eb2e", "value":"54", "variable":"Humidity" },{ "id":11, "service":"LYWSD0338eb2e", "value":"-85", "variable":"RSSI" },{ "id":12, "service":"LYWSD0338eb2e", "value":"11.9", "variable":"DewPoint" },{ "id":13, "service":"LYWSD03a59e0c", "value":"a4c138a59e0c", "variable":"mac" },{ "id":14, "service":"LYWSD03a59e0c", "value":"20.9", "variable":"Temperature" },{ "id":15, "service":"LYWSD03a59e0c", "value":"58", "variable":"Humidity" },{ "id":16, "service":"LYWSD03a59e0c", "value":"-91", "variable":"RSSI" },{ "id":17, "service":"LYWSD03a59e0c", "value":"12.3", "variable":"DewPoint" },{ "id":18, "service":"power_BedroomTV", "value":"ON", "variable":"Switch2" },{ "id":19, "service":"power_BedroomTV", "value":"ON", "variable":"Switch1" },{ "id":20, "service":"ENERGY", "value":"0", "variable":"Total" },{ "id":21, "service":"ENERGY", "value":"table: 0x556c23b0f060", "variable":"Power" },{ "id":22, "service":"ENERGY", "value":"table: 0x556c23b0f100", "variable":"ApparentPower" },{ "id":23, "service":"ENERGY", "value":"table: 0x556c237e4cd0", "variable":"Current" },{ "id":24, "service":"ENERGY", "value":"121", "variable":"Voltage" },{ "id":25, "service":"ENERGY", "value":"table: 0x556c237e48d0", "variable":"Factor" },{ "id":26, "service":"ENERGY", "value":"0", "variable":"Period" },{ "id":27, "service":"ENERGY", "value":"table: 0x556c23b0f1d0", "variable":"ReactivePower" },{ "id":28, "service":"ENERGY", "value":"0", "variable":"Yesterday" },{ "id":29, "service":"ENERGY", "value":"2021-04-04T05:29:11", "variable":"TotalStartTime" },{ "id":30, "service":"ENERGY", "value":"0", "variable":"Today" },{ "id":31, "service":"ENERGY", "value":"60", "variable":"Frequency" },{ "id":32, "service":"ENERGY", "value":"0", "variable":"Power/1" },{ "id":33, "service":"ENERGY", "value":"0", "variable":"Power/2" },{ "id":34, "service":"ENERGY", "value":"0", "variable":"ApparentPower/1" },{ "id":35, "service":"ENERGY", "value":"0", "variable":"ApparentPower/2" },{ "id":36, "service":"ENERGY", "value":"0", "variable":"Current/1" },{ "id":37, "service":"ENERGY", "value":"0", "variable":"Current/2" },{ "id":38, "service":"ENERGY", "value":"0", "variable":"Factor/1" },{ "id":39, "service":"ENERGY", "value":"0", "variable":"Factor/2" },{ "id":40, "service":"ENERGY", "value":"0", "variable":"ReactivePower/1" },{ "id":41, "service":"ENERGY", "value":"0", "variable":"ReactivePower/2" },{ "id":42, "service":"power_BedroomTV", "value":"50", "variable":"Sleep" },{ "id":43, "service":"power_BedroomTV", "value":"56414", "variable":"UptimeSec" },{ "id":44, "service":"power_BedroomTV", "value":"Dynamic", "variable":"SleepMode" },{ "id":45, "service":"power_BedroomTV", "value":"OFF", "variable":"POWER2" },{ "id":46, "service":"power_BedroomTV", "value":"OFF", "variable":"POWER1" },{ "id":47, "service":"power_BedroomTV", "value":"125", "variable":"Heap" },{ "id":48, "service":"Wifi", "value":"CD", "variable":"SSId" },{ "id":49, "service":"Wifi", "value":"FE:9F:DB:F5:A0:11", "variable":"BSSId" },{ "id":50, "service":"Wifi", "value":"0T00:00:26", "variable":"Downtime" },{ "id":51, "service":"Wifi", "value":"11", "variable":"Channel" },{ "id":52, "service":"Wifi", "value":"86", "variable":"RSSI" },{ "id":53, "service":"Wifi", "value":"2", "variable":"LinkCount" },{ "id":54, "service":"Wifi", "value":"-57", "variable":"Signal" },{ "id":55, "service":"Wifi", "value":"1", "variable":"AP" },{ "id":56, "service":"power_BedroomTV", "value":"2", "variable":"MqttCount" },{ "id":57, "service":"power_BedroomTV", "value":"0T15:40:14", "variable":"Uptime" },{ "id":58, "service":"power_BedroomTV", "value":"19", "variable":"LoadAvg" }], "status":-1, "subcategory_num":0, "time_created":1618456263 }]
-
@therealdb said in openLuup: Tasmota MQTT Bridge:
@archers I need verbose logs. I have mine setup this way to control a dehumidifier and it’s working ok.
I set the debugmode variable to 1. In the ReadMe it says logs could be captured by navigating to http://VeraIP/cgi-bin/cmh/log.sh?Device=LuaUPnP but this does not seem to work, is it another url for OpenLuup? Or can I find the log somewhere in cmh-ludl?
Just to clarify, the device is still not connected to anything (no IP given) could that be the reason, or should it work anyway?
-
Latest openLuup development version (v21.5.10, and yes, we're back to that branch) includes fixes for Tasmota (and Shelly) Historian, including archive rules for Temperature / Humidity / Battery variable names.
Please Note: you should reload openLuup once more after updating, to get the Historian and Grafana to sync properly.
-
@therealdb said in openLuup: Tasmota MQTT Bridge:
@archers it should work regardless. The openluup log page is under /console
Aha, I thought it ended up in a separate logfile.
This is what I get in the log when changing the temperature of the device (no 50):
2021-05-10 22:59:37.312 openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=50&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&NewCurrentSetpoint=15 HTTP/1.1 tcp{client}: 0x1ec57b0 2021-05-10 22:59:37.313 luup.call_action:: 50.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.SetCurrentSetpoint 2021-05-10 22:59:37.314 luup_log:50: VirtualDevices[3.0-beta2@50](actionSetCurrentSetpoint@86):actionSetCurrentSetpoint(50,"15","Off","Heating") 2021-05-10 22:59:37.314 luup_log:50: VirtualDevices[3.0-beta2@50](actionSetCurrentSetpoint@90):actionSetCurrentSetpoint: skipped 2021-05-10 22:59:37.315 openLuup.server:: request completed (44 bytes, 1 chunks, 2 ms) tcp{client}: 0x1ec57b0 2021-05-10 22:59:50.043 openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x1ec57b0
-
@akbooer OK that worked. Thx
Edit: Humidity variables are back. Looks like about 4 hours passed
I still do not see the humidity variables on the cache page though. The humidity values have recently updated as a scene I run based on humidity trigger points, fired about an hour ago. -
@akbooer One small error creating the energy variables
2021-05-10 17:22:42.275 openLuup.context_switch:: ERROR: [dev #0] ./openLuup/whisper.lua:662: Cannot create file '%s' 2021-05-10 17:22:42.275 openLuup.scheduler:: 30001.ENERGY.Current/1 ERROR ./openLuup/whisper.lua:662: Cannot create file '%s' function: 0x5633603dd490 2021-05-10 17:22:42.276 openLuup.context_switch:: ERROR: [dev #0] ./openLuup/whisper.lua:662: Cannot create file '%s' 2021-05-10 17:22:42.276 openLuup.scheduler:: 30001.ENERGY.Current/2 ERROR ./openLuup/whisper.lua:662: Cannot create file '%s' function: 0x5633603dd490
-
@archers said in openLuup: Tasmota MQTT Bridge:
This is what I get in the log when changing the temperature of the device (no 50):
Looking at the logs, you're setting the temperature while the heater is off, so it's skipped. Do you want to turn it on if the temperature is below the target?
-
@buxton said in openLuup: Tasmota MQTT Bridge:
Humidity variables are back. Looks like about 4 hours passed
Yes, that's not unexpected. In fact, it requires two variable updates before the variable appears on the historian list (because many, otherwise untinteresting, variables are updated once at startup.)
@buxton said in openLuup: Tasmota MQTT Bridge:
One small error creating the energy variables
Ah yes, those pesky topic separators '/' in the variable name – I knew it would come back to bite me. They are, of course, in the Unix file world, directory path separators. Some work required on the HIstorian filename handling...
-
@therealdb said in openLuup: Tasmota MQTT Bridge:
Looking at the logs, you're setting the temperature while the heater is off, so it's skipped. Do you want to turn it on if the temperature is below the target?
I created a new device just to start from fresh:
When I try to change the dropdown from "off" to "Heat" it reverts back after I e.g. change rooms or reload the browser. The same thing when changing the temperature. Should it not stay at the value I set? I may be missing something obvious here on how the heater controller works, since it is the first time I play around with one.
The current temp was at 2000 when the device was created, tried changing it to e.g. 20, but makes no difference.
Some log entries from when changing the values:
2021-05-11 16:04:04.239 openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=52&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&NewCurrentSetpoint=21 HTTP/1.1 tcp{client}: 0x2697800 2021-05-11 16:04:04.242 luup.call_action:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.SetCurrentSetpoint 2021-05-11 16:04:04.243 openLuup.server:: request completed (44 bytes, 1 chunks, 2 ms) tcp{client}: 0x2697800 2021-05-11 16:04:09.775 openLuup.server:: GET /cmh/skins/default/img/devices/device_states/dimmable_light_30.png HTTP/1.1 tcp{client}: 0x2697800 2021-05-11 16:04:09.777 openLuup.server:: request completed (938 bytes, 0 chunks, 0 ms) tcp{client}: 0x2697800 2021-05-11 16:04:16.134 openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x2697800 2021-05-11 16:05:43.757 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=741810207&Timeout=60&MinimumDelay=1500&_=1620741805209 HTTP/1.1 tcp{client}: 0x2882ed8 2021-05-11 16:05:45.244 openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=52&serviceId=urn:upnp-org:serviceId:HVAC_UserOperatingMode1&action=SetModeTarget&NewMode=HeatOn HTTP/1.1 tcp{client}: 0x2d32838 2021-05-11 16:05:45.246 luup.call_action:: 52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.SetModeTarget 2021-05-11 16:05:45.247 openLuup.server:: request completed (39 bytes, 1 chunks, 1 ms) tcp{client}: 0x2d32838 2021-05-11 16:05:53.818 openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x2d32838
Log from when the device was created:
2021-05-11 10:05:35.089 luup.create_device:: [52] D_VirtualHeater1.xml / I_VirtualHeater1.xml / D_Heater1.json (urn:schemas-upnp-org:device:Heater:1) 2021-05-11 10:05:35.099 openLuup.server:: request completed (6440 bytes, 0 chunks, 34 ms) tcp{client}: 0x1c6c030 2021-05-11 10:05:35.099 openLuup.scheduler:: [52] VirtualHeater2 device startup 2021-05-11 10:05:35.099 luup_log:52: VirtualHeater starting... 2021-05-11 10:05:35.100 luup_log:52: VirtualDevices[3.0-beta2@52]:Plugin starting 2021-05-11 10:05:35.100 luup.device_message:: device=52, status=4, message=Starting..., timeout=5, source=VirtualDevices 2021-05-11 10:05:35.100 luup_log:52: VirtualDevices[3.0-beta2@52]:Child #52 - "VirtualHeater2" 2021-05-11 10:05:35.101 luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.DebugMode was: EMPTY now: 0 #hooks:0 2021-05-11 10:05:35.101 luup.variable_set:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1.CurrentSetpoint was: EMPTY now: 18 #hooks:0 2021-05-11 10:05:35.102 luup.variable_set:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint was: EMPTY now: 18 #hooks:0 2021-05-11 10:05:35.102 luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.TemperatureDevice was: EMPTY now: 0 #hooks:0 2021-05-11 10:05:35.103 luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerURL was: EMPTY now: http:// #hooks:0 2021-05-11 10:05:35.103 luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerOffURL was: EMPTY now: http:// #hooks:0 2021-05-11 10:05:35.103 luup.attr_set:: 52.subcategory_num = 2 2021-05-11 10:05:35.106 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeTarget 2021-05-11 10:05:35.108 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeStatus 2021-05-11 10:05:35.111 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1.CurrentSetpoint 2021-05-11 10:05:35.113 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint 2021-05-11 10:05:35.116 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature 2021-05-11 10:05:35.116 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.Configured was: 0 now: 1 #hooks:0 2021-05-11 10:05:35.116 luup.set_failure:: status = 0 2021-05-11 10:05:35.117 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0 2021-05-11 10:05:35.117 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: EMPTY now: 0 #hooks:0 2021-05-11 10:05:35.117 openLuup.scheduler:: [52] VirtualHeater2 device startup completed: status=true, msg=Ready, name=VirtualDevices 2021-05-11 10:05:35.626 openLuup.server:: request completed (4456 bytes, 1 chunks, 8545 ms) tcp{client}: 0x20a2fc0 2021-05-11 10:05:35.714 openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=679125970&_=1620678904534 HTTP/1.1 tcp{client}: 0x20a2fc0 2021-05-11 10:05:36.145 openLuup.server:: request completed (764639 bytes, 48 chunks, 429 ms) tcp{client}: 0x20a2fc0 2021-05-11 10:05:38.584 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=679159576&Timeout=60&MinimumDelay=1500&_=1620678904535 HTTP/1.1 tcp{client}: 0x20a2fc0 2021-05-11 10:05:41.932 openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x1c6c030
-
That's great. The next release will have a new openLuup > Historian > Rules page so that you can see what patterns are being used to match variables for archiving. Not yet editable, but that may come in future. Feel free to ask for more/better rules and I can put them into another release, or tell you how to add them in Lua Startup.
-
-
@archers said in openLuup: Tasmota MQTT Bridge:
2021-05-11 10:05:35.103 luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerURL was: EMPTY now: http:// #hooks:0
2021-05-11 10:05:35.103 luup.variable_set:: 52.urn:bochicchio-com:serviceId:VirtualHeater1.SetPowerOffURL was: EMPTY now: http:// #hooks:0This is by design. As you can see, you've not set SetPowerURL and SetPowerOffURL to anything significant, like the mqtt message, so it's not sending anything, and it's acting with the default behavior: if you're not replying with 200-ish HTTP response, it will not change variables. When using mqtt:// prefix, it will update immediately.
I'll work on this anyway, since it's not sending temperature command at the moment, but I think it's a good addition in your use case - and to other people as well.
Please try with mqtt commands and let me know, because I have it working good.
EDIT: it's done, just set SetSetpointURL variable to
mqtt://cmnd/TasmotaIR/IRhvac/=/{"Vendor":"FUJITSU_AC","Model":1,"Mode":"Heat","Power":"On","Celsius":"On","Temp":%s,"FanSpeed":"Auto","SwingV":"Off","SwingH":"Off","Quiet":"Off","Turbo":"Off","Econo":"Off","Light":"Off","Filter":"Off","Clean":"Off","Beep":"Off","Sleep":-1}
(notice the %s). it's sending the temperature that's set. it's beta3 on GitHub, from master branch.
-
@therealdb my feeling was that I had missed something.
Yes I think it could be a good usecase.Edit: I got to send the Mqtt message a few times, but not every time. Not sure why it does not send every time though. Does it matter if it is "off" or "heat"?
Edit 2: It seems as if it works! Mode "off" and then the set temp sends the Mqtt message. Maybe if was a poll delay or something. I will test some more.
I tried to add the above mqtt:// into the SetSetpoint URL but nothing seems to be sent, i.e. nothing is appearing in the Tasmota Console.This is what I see in the log (device no 52):
2021-05-12 20:18:02.023 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=843427346&Timeout=60&MinimumDelay=1500&_=1620843427214 HTTP/1.1 tcp{client}: 0x1b09e50 2021-05-12 20:18:14.970 openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=52&serviceId=urn:upnp-org:serviceId:TemperatureSetpoint1_Heat&action=SetCurrentSetpoint&NewCurrentSetpoint=19 HTTP/1.1 tcp{client}: 0x2204008 2021-05-12 20:18:14.972 luup.call_action:: 52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.SetCurrentSetpoint 2021-05-12 20:18:14.973 openLuup.server:: request completed (44 bytes, 1 chunks, 2 ms) tcp{client}: 0x2204008 2021-05-12 20:18:20.877 openLuup.server:: GET /console?page=log.1 HTTP/1.1 tcp{client}: 0x2204008 2021-05-12 20:18:20.981 openLuup.server:: request completed (185478 bytes, 0 chunks, 102 ms) tcp{client}: 0x2204008 2021-05-12 20:18:21.107 openLuup.server:: GET /favicon.ico HTTP/1.1 tcp{client}: 0x2204008 2021-05-12 20:18:21.107 openLuup.servlet:: file not found:favicon.ico 2021-05-12 20:18:21.108 openLuup.server:: request completed (126 bytes, 0 chunks, 0 ms) tcp{client}: 0x2204008 2021-05-12 20:18:21.108 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x2204008 2021-05-12 20:18:23.314 openLuup.io.server:: HTTP:3480 connection from 192.168.1.145 tcp{client}: 0x1c7ed70 2021-05-12 20:18:23.316 openLuup.server:: GET /console?page=log HTTP/1.1 tcp{client}: 0x1c7ed70
I also tried with a number, e.g. "20" instead of %s but no difference.
Startup log, it seems as if I have the right version:
2021-05-12 20:29:18.833 luup_log:52: VirtualHeater starting... 2021-05-12 20:29:18.834 luup_log:52: VirtualDevices[3.0-beta3@52]:Plugin starting 2021-05-12 20:29:18.834 luup.device_message:: device=52, status=4, message=Starting..., timeout=5, source=VirtualDevices 2021-05-12 20:29:18.834 luup_log:52: VirtualDevices[3.0-beta3@52]:Child #52 - "VirtualHeater2" 2021-05-12 20:29:18.835 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeTarget 2021-05-12 20:29:18.837 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:HVAC_UserOperatingMode1.ModeStatus 2021-05-12 20:29:18.838 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1.CurrentSetpoint 2021-05-12 20:29:18.840 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSetpoint1_Heat.CurrentSetpoint 2021-05-12 20:29:18.841 luup.variable_watch:: callback=virtualThermostatWatch, watching=52.urn:upnp-org:serviceId:TemperatureSensor1.CurrentTemperature 2021-05-12 20:29:18.841 luup.set_failure:: status = 0 2021-05-12 20:29:18.841 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0 2021-05-12 20:29:18.842 luup.variable_set:: 52.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0 2021-05-12 20:29:18.842 openLuup.scheduler:: [52] VirtualHeater2 device startup completed: status=true, msg=Ready, name=VirtualDevices