Another transition from Vera to OpenLuup And now to HASS - PerH
-
Definitely some weird stuff going on either on your network or in the web. When you get a chance to look at it, I would definitely recommend moving to local cdn. I pushed a bunch of updates to @amg0's repo on GitHub last week and he also updated their web version. You should see them on the next release.
-
I know there is some issue with the LAN, as I just changed routers.. Ubiquiti Edgerouter X setup needs a higher level of network knowledge than I have, so i have a thread on the ubiquiti forum.
Local CDN sounds interesting, what is it? i asumed AltUI is looking to a lisence server?
-
Rather than paraphrasing, look at the first file here:
In short, ALTUI is very dependent on your network connection. You can localize almost every call it makes for these cdn which are files/tools needed by the browser to display the UI. Localizing them enables you to not rely on these servers but to run the whole thing off of your openLuup/ALTUI server. It is much faster when open locally but relies on your home internet connection if you are logging in remotely. It still look for the license server but ALTUI still works for the most part even without a license...
-
Merry christmas ppl, I just have a question regarding "nonce reports".. I noticed that theres a huge amount of them in the zniffer history, like 100 request/report messages to one device in just 1.5 hours?? Can that be necessary?
Notice that this is just sent from controller to one device..
I have a reactor that controls all common area lights, and have seen that some lights don't react to it some times.. not surprised if there's constant flows of nonce reports all the time?
-
NONCE report are a response from the controller to the device asking for it. It is as you can see the security key. What device is it? It seems indeed abnormal... I would not know why the device would be trying to exchange security keys every second.
-
It's a fibaro dimmer.. I know how much you love those. Probably some setting then?
-
I deleted your double post... Yeah not sure what is going on and what setting could possibly cause this. Maybe try power cycling the switch to see if it goes away? It seems to be stuck somehow.
One other thing to look at is whether you have a scene somewhere trying to send commands to this device at a high frequency since I am seeing also a number of NONCE get calls issued by the controller. Something must be triggering it.
-
Looked through, and it looks like this is a common thing for all the mains powered units attached secure. a lot of "nonce activity"!
Here's a different fibaro unit:
I can't see why they would have so much back&forth with this, and i don't have any scenes at all, just reactors. And this seems to happen at a steady pace, there's not that automation going on here.
Can you show an example of this "nonce" message communication at your setup?
-
I basically see none of it unless a scene triggers them. I for example have an Aeotec HEM which is securely included and I see the exchange when it reports the values of the HEM. I see this also when I trigger a switch on and off or when I trigger a security sensor. It is always connected to an action. Is it always the same type of device?
-
I think i might have found the "nonce" culprit!
the app "Periodical Sensor Polling" in z-way was set up to poll all devices every 10 minutes.. Why would one want that if the sensors always sends an update on changes (configured on the device)? -
I finally made the Domoticz link work, and then ported all Zigbee devices to the much better zigate plugin there. No change in latency at all, very sharp responses to door and motion sensors. Happy!
This plugin has its own GUI, and is almost structurally standalone. I've contacted the developers to ask if its possible with a direct API and to run it as a service to cut domoticz out of the chain..
I can now confirm that TRADFRI and Aqara will work together just fine, with repeaters helping for both systems:
-
I have to applaud your resilience in finding yet a novel integration of zigbee into openLuup. I looked at it a while ago for just a few minutes before giving up with the thought that the plugin was broken and moved on to something else.
In many ways I envy your integration. I came to realize that I had mentally split my setup into 2 major controller categories:
The local, z-wave and zigbee which needed to be stable, fast and 100% reliable, almost never requiring any updates.
The cloud side which I tried to minimize to the very essential and would constantly require updates due to cloud APIs changing.
I partially failed by running my zigbee on home assistant which also is my cloud integration portal and is constantly getting updates. You just did exactly what I wanted to do... -
@therealdb: Yes, it would definately require some writing on the plugin, but then it would also open for more users.. we'll see!
There is some really good plugins and features in Domoticz as well, so its OK even if the plugin stays attached to it, as long as the performance stays good. Next plugin for me to install now is the Xiaomi Vacuum.
-
Finally starting to get the docker thing here, and currently i've got z-way 3.1.3, domoticz and miio-server (for the vacuum) running in dockers. Nice to se that there's no performance reduction with this either. I'd also like to get grafana and influxdb into dockers.
Plan now is to have some daily backup routine. I was thinking mabye just to have Reactor do
os.execute cp -rf <docker volume folder> <backup folder on SSD>
sometime at night. Any thoughts? -
Per, how are you planning to handle daemonizing? I've been playing with docker-compose, which seems a good way to remove the need to have a command line with a lot of error-prone parameters that users must type.
-
Yes, i've made a docker-compose file that brings up all the dockers and set them up on the same internal bridge network with static IP's. Then all intercom is done with the same IP's on any hardware, so theres not much to set up other than copying in the volume backups.
Daemonizing was a new word for me, in this context you were referring to automating the install, right?
-
By "daemonizing" I mean starting them as a daemon, which is in Unix parlance a console-less process that runs in the background (a service, if you will).
-
The closest I have come to this has been running them as systemctl services. My single VM actually runs everything that way. I did so for MSR as well but no docker for me. You can put all of these command within the service file? I am actually autostarting all of my services in a sequence with dependencies: example: Do a socat reload before starting z-way. Then when z-way is up start openluup then start habridge then start homekitbridge... etc...
-
Well, as long as you state restart policy "restart: always" or "restart: unless stopped" in the docker-compose file, it will start that container on reboot as long as the docker daemon itself starts.. docker installed itself as a service, so i haven't thought about it really.
Just to have it said; the docker-compose is just a script to rig up the containers with the correct settings. This is done once, after that the restart policy you set for the containers decides how they will live from there. you can set up as many containers as you like in one compose file.