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.pretty
but 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:0
Also 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}: 0x17e96f0
So 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 @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
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, stabilization
Grab 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, © 2019
AltUI 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=2551
In 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:0
And 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 hours
All 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=2550
So 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.
@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: Shelly Bridge plugin
-
reload luup devices have now failed
log2021-04-17 21:04:07.840 openLuup.scheduler:: [25] BroadLink-Mk2 device startup completed: status=true, msg=All OK, name=BroadLink_Mk2 2021-04-17 21:04:07.841 openLuup.scheduler:: [46] Shelly device startup 2021-04-17 21:04:07.841 luup.set_failure:: status = 0 2021-04-17 21:04:07.842 luup.variable_set:: 46.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0 2021-04-17 21:04:07.843 luup.variable_set:: 46.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0 2021-04-17 21:04:07.843 openLuup.scheduler:: [46] Shelly device startup completed: status=true, msg=OK, name=ShellyBridge 2021-04-17 21:04:07.844 openLuup.scheduler:: [47] Tasmota device startup 2021-04-17 21:04:07.844 luup.set_failure:: status = 0 2021-04-17 21:04:07.844 luup.variable_set:: 47.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0 2021-04-17 21:04:07.845 luup.variable_set:: 47.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0 2021-04-17 21:04:07.846 openLuup.scheduler:: [47] Tasmota device startup completed: status=true, msg=OK, name=TasmotaBridge 2021-04-17 21:04:07.847 luup_log:3: ALTUI: UPNPregisterDataProvider(3,Vera@192.168.1.11,http://127.0.0.1:3480/data_request?id=lr_HTTP_VeraBridgeMirror_192.168.1.11,[{2021-04-17 21:04:21.212 openLuup.server:: request completed (835 bytes, 0 chunks, 0 ms) tcp{client}: 0xfc86dd0 2021-04-17 21:04:21.214 openLuup.server:: GET /luvd/D_GenericShellyDevice.xml HTTP/1.1 tcp{client}: 0xf37a830 2021-04-17 21:04:21.215 openLuup.server:: request completed (293 bytes, 0 chunks, 0 ms) tcp{client}: 0xf37a830 2021-04-17 21:04:21.217 openLuup.server:: GET /luvd/D_Reactor.xml HTTP/1.1 tcp{client}: 0xfe92080 2021-04-17 21:04:21.221 openLuup.server:: request completed (1156 bytes, 0 chunks, 0 ms) tcp{client}: 0xfe92080 2021-04-17 21:04:21.222 openLuup.server:: GET /luvd/D_ReactorSensor.xml HTTP/1.1 tcp{client}: 0xff353d8 2021-04-17 21:04:21.224 openLuup.server:: request completed (1572 bytes, 0 chunks, 0 ms) tcp{client}: 0xff353d8 2021-04-17 21:04:21.226 openLuup.server:: GET /luvd/D_DimmableRGBLight1.xml HTTP/1.1 tcp{client}: 0xfe940f8 2021-04-17 21:04:21.229 openLuup.server:: request completed (1507 bytes, 0 chunks, 0 ms) tcp{client}: 0xfe940f8 2021-04-17 21:04:21.253 openLuup.server:: GET /luvd/D_ShellyBridge.xml HTTP/1.1 tcp{client}: 0xfd25c78will now restart mosquitto without deleting devices.
-
Restarting mosquitto brings devices back to life.
log
2021-04-17 21:09:39.969 openLuup.io.server:: MQTT:1884 connection closed tcp{client}: 0xff53448 2021-04-17 21:09:39.972 openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0xff53448 2021-04-17 21:09:39.973 openLuup.mqtt:: localhost.bridge-01 UNSUBSCRIBE from # tcp{client}: 0xff53448 2021-04-17 21:09:45.774 openLuup.io.server:: MQTT:1884 connection from 192.168.1.25 tcp{client}: 0xf527b20 2021-04-17 21:09:45.823 openLuup.mqtt:: localhost.bridge-01 SUBSCRIBE to # tcp{client}: 0xf527b20 2021-04-17 21:09:45.826 luup.shelly:46: New Shelly announced: shellyix3-rear 2021-04-17 21:09:45.827 luup.attr_set:: 30004.ip = 192.168.1.105 2021-04-17 21:09:45.828 luup.attr_set:: 30004.mac = E8DB84D6E80A 2021-04-17 21:09:45.829 luup.attr_set:: 30004.model = SHIX3-1 2021-04-17 21:09:45.829 luup.attr_set:: 30004.firmware = 20210413-154502/v1.10.2-gb89901a 2021-04-17 21:09:45.906 luup.shelly:46: New Shelly announced: shelly1-93A847 2021-04-17 21:09:45.907 luup.attr_set:: 30002.ip = 192.168.1.102 2021-04-17 21:09:45.908 luup.attr_set:: 30002.mac = BCDDC293A847 2021-04-17 21:09:45.908 luup.attr_set:: 30002.model = SHSW-1 2021-04-17 21:09:45.909 luup.attr_set:: 30002.firmware = 20210415-125832/v1.10.3-g23074d0 2021-04-17 21:09:46.040 luup.shelly:46: New Shelly announced: shelly1-93FC56 2021-04-17 21:09:46.041 luup.attr_set:: 30005.ip = 192.168.1.100 2021-04-17 21:09:46.042 luup.attr_set:: 30005.mac = BCDDC293FC56 2021-04-17 21:09:46.043 luup.attr_set:: 30005.model = SHSW-1 2021-04-17 21:09:46.043 luup.attr_set:: 30005.firmware = 20210415-125832/v1.10.3-g23074d0 2021-04-17 21:09:46.360 luup.shelly:46: New Shelly announced: shellyix3-front 2021-04-17 21:09:46.361 luup.attr_set:: 30001.ip = 192.168.1.106 2021-04-17 21:09:46.362 luup.attr_set:: 30001.mac = E8DB84D6C6C8 2021-04-17 21:09:46.363 luup.attr_set:: 30001.model = SHIX3-1 2021-04-17 21:09:46.363 luup.attr_set:: 30001.firmware = 20210413-154502/v1.10.2-gb89901a 2021-04-17 21:09:51.275 luup.tasmota:47: JSON error: Expected value but found invalid token at character 1 2021-04-17 21:09:51.594 luup.tasmota:47: JSON error: Expected value but found invalid token at character 1 2021-04-17 21:09:51.647 luup.tasmota:47: JSON error: Expected value but found invalid token at character 1 2021-04-17 21:09:51.936 luup.tasmota:47: JSON error: Expected value but found invalid token at character 1 2021-04-17 21:09:54.170 luup.shelly:46: New Shelly announced: shelly1-93BEFE 2021-04-17 21:09:54.171 luup.attr_set:: 30007.ip = 192.168.1.101 2021-04-17 21:09:54.172 luup.attr_set:: 30007.mac = BCDDC293BEFE 2021-04-17 21:09:54.172 luup.attr_set:: 30007.model = SHSW-1 2021-04-17 21:09:54.173 luup.attr_set:: 30007.firmware = 20210415-125832/v1.10.3-g23074d0 2021-04-17 21:10:00.117 luup_log:0: 13Mb, 0.8%cpu, 0.0days -
OK Mosquitto reports bridge disconnect and 5 seconds later reconnects, when i reload luup.
I then power off 1 device and back on, Mosquitto reports device already connected,closing connection then new client shelly device and ip.
back in AltUI the device i power cycled is working , all other still not.
-
Here's what I found with my Shellies (more to come, I have a couple more on the test bench, not already connected).
- Shelly 1PM seems OK. Ext temperatures are not mapped, but the variable is crated:
This should be easily mapped. I don't have humidity attached, but it's similar, looking at the docs. - Shelly plug is not correctly mapped. Here's the announce payload:
{"id":"shelly-veraplug","model":"SHPLG-S","mac":"XXX","ip":"192.168.1.46","new_fw":true,"fw_ver":"20210323-105718/v1.10.1-gf276b51"}It's mapped as a scene control, instead of a plug. Power variables are correctly saved.
As I've said, I have buttons, uni and EM on my test bench and I'll add them very soon, so I could help with code if necessary @akbooer .
- Shelly 1PM seems OK. Ext temperatures are not mapped, but the variable is crated:
-
Try v21.4.18 to see if the plug now works (it will create a separate child device.)
@akbooer all set now for shelly plug!
EDIT: I think category_num and subcategory_num should be set to at least 3/0, so the UI could filter them better.
So, the recommendation for Shelly 1 PM used as detached relay (input separated from relay) is to manually use the variables?
-
Good news on the plug. I haven't yet considered setting the (sub)category automatically, but it should be easy enough.
For any Shelly with switches, the generic device has the raw variables but also they're treated as a scene controller, so you have
sl_SceneActivatedandLastSceneTimeavailable to you. -
Good news on the plug. I haven't yet considered setting the (sub)category automatically, but it should be easy enough.
For any Shelly with switches, the generic device has the raw variables but also they're treated as a scene controller, so you have
sl_SceneActivatedandLastSceneTimeavailable to you.@akbooer I have a Shelly Plug (not the "S" variant) that I now finally setup on my test Pi to try the Shelly bridge.
The plug shows as it should in the Shellies room:
The following variables are mapped:
The payload is:
{"id":"shellyplug-6CC126","model":"SHPLG2-1","mac":"xxx","ip":"192.168.1.30","new_fw":false,"fw_ver":"20201124-092420/v1.9.0@57ac4ad8"}However no child devices show up for the plug what I can see.
Is this something that can be added to the bridge, or have I missed anything in my setup?(running OpenLuup v 21.4.18)
-
@akbooer I have a Shelly Plug (not the "S" variant) that I now finally setup on my test Pi to try the Shelly bridge.
The plug shows as it should in the Shellies room:
The following variables are mapped:
The payload is:
{"id":"shellyplug-6CC126","model":"SHPLG2-1","mac":"xxx","ip":"192.168.1.30","new_fw":false,"fw_ver":"20201124-092420/v1.9.0@57ac4ad8"}However no child devices show up for the plug what I can see.
Is this something that can be added to the bridge, or have I missed anything in my setup?(running OpenLuup v 21.4.18)
-
@akbooer that seems to have worked, now I get the child device and can control the plug on/off, thanks!
@akbooer now on to my second Shelly, a Shelly Uni.
Same thing here, I assume, no child devices are created some mapping is required.
(For my Uni I have the two relays connected to two relays reading two states from the alarm, and no buttons connected to control the two inputs. In other words in my application I do not really need the input child devices.)It gets created as it should:
Variables:
The temperature gets mapped correctly.
The two "relay" variables are the outputs for each channel are also as they should from what I can see.Payload:
{"id":"shellyuni-483FDA82C252","model":"SHUNI-1","mac":"xxx","ip":"192.168.1.31","new_fw":false,"fw_ver":"20201124-093042/v1.9.0@57ac4ad8"}I think the "input" variables are the two buttons that you can control as a user that need child devices.
If I remember it correctly @therealdb also has a Uni if you need more input from a second use case.
-
@akbooer now on to my second Shelly, a Shelly Uni.
Same thing here, I assume, no child devices are created some mapping is required.
(For my Uni I have the two relays connected to two relays reading two states from the alarm, and no buttons connected to control the two inputs. In other words in my application I do not really need the input child devices.)It gets created as it should:
Variables:
The temperature gets mapped correctly.
The two "relay" variables are the outputs for each channel are also as they should from what I can see.Payload:
{"id":"shellyuni-483FDA82C252","model":"SHUNI-1","mac":"xxx","ip":"192.168.1.31","new_fw":false,"fw_ver":"20201124-093042/v1.9.0@57ac4ad8"}I think the "input" variables are the two buttons that you can control as a user that need child devices.
If I remember it correctly @therealdb also has a Uni if you need more input from a second use case.
@archers said in openLuup: Shelly Bridge plugin:
If I remember it correctly @therealdb also has a Uni if you need more input from a second use case
I literally have bought anything from them, but I've not fully deployed every device. I'm still waiting for my Uni and EM to be inserted. the EMs will soon monitor my AC, so I could detect if it's running or not (I have to use two switchbots to turn it on/off, because it's still under warranty and I could not mess with the original thermostat).
All that said, I'm voting for automatic creation of child temp/humidity sensors, and for Uni to create relays and inputs separately. That's what most people will do, anyway.
