Jump to content


c4Forums Member
  • Content count

  • Joined

  • Last visited

About VegardK

  • Rank
    Control4 End User
  • Birthday February 21

Contact Methods

  • Skype

Profile Information

  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is true. Therefor trying to see if there is any others with information to what is normal for Control4. Cause this is different than other systems like you say.
  2. Thanks. Well then running on 6+ is not bad. But then this system should have more cores. But then again it would just pile up even more from my understanding. Peaking on 9 I don't think is good though. But If I look at the EA1 the CPU is averaging 5% with min 4% and max 42%. So thats not bad either and way within The memory on the other hand seems more worrisome. The Available memory is averaging 21%. Where the lowest 13% left and max at 24% left of memory. Is this something I should be more aware of? On screenshot of klaue2 it can seem that the EA5 there is having around 50% left... Its good to understand all this cause in terms of system capacity and planing, when should you go for a EA3 instead of EA1 and so on. When not basing it on how many sources you need. I like to use the EA3 a lot as it has PoE power, and I can then reboot it on the switch port if needed.
  3. Its never going to be easy. Its only gonna get harder. One need to use all the tools you can get in many ways. But its true what you say the problem lies with programming, bugs (lots of those around) and hardware failure. But then again a log would easily show if a you program something that would spam the system increasing its load. Or if you see some hardware responding worse over time. And as mentioned not doing a upgrade on a system, if you can see its close to limits, before those limits are dealt with.
  4. I guess only way to find out is over time. comparing systems. Comparing those that works well to those that does not work or fails. Anyway monitoring key aspects of systems I think is a good thing to do. Being early out and also in cases come before, telling the customer there is issues with their system and we are working on it. Before the customer even know there is a problem is good. Also most likely easier to tell a customer that you should upgrade your system cause you are on the limit with it. Not adding more features to a system that are on the edge, before doing some upgrades to the system.
  5. The tooling (PRTG) hasn't been set with any warnings yet, as I need to set them. And rule of thumb would be to have a system running less than 0,7 as the system then has space on the "road". And then set an error above 1.0 as there is no more space on the "road". And 1 core has 1 capacity so 4 cores would mean 4.0 would be max capacity. And in this case setting after this rule would go into a constant error. But as you say it doesn't really have to be bad. It might be Control4 has set so that it should always be on limit, and have processes waiting to do some "not that important" jobs. This is monitoring from 1 system only as well, I hope over time to gather this from several systems including EA3, EA5 etc. Once I have that I can be more sure of what is normal and not. I might take this to Control4 them self, and ask them what they say is ok an why.
  6. Yeah all is relative hence this thread Its the same guess as me that there is processes/drivers etc waiting to be processed. And that they don't need much capacity to run from the CPU, hence the low CPU %. I don't get monitoring from the the disk other than space, so cannot put that into the equation.
  7. In linux, average load is not the same as CPU utilization in %. CPU load in % is this. But that's how well each process is using the CPU not how many processes waiting to be processed. Take a look at this link about load: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages So the 4 cores that the EA1 has the max load would be 4.0. But the system in my case is running 6+. Meaning processes is waiting in line to be handled. Then each process does not utilize the CPU that much, therefor low CPU utilization but high load. I guess this comes down to the fact that the system keep reading/writing a lot both from drivers and other systems, as well as reading all programming all the time.
  8. Sure thing This is for last 2 hours.
  9. Yes this is from the PRTG monitoring system I use. If you look at the "SNMP Load Average" in first image you will see it's 6,07 (1min). But 5 and 15 min is much the same, so load is quite constant. CPU load in % is not the same as system load. A processor can have low CPU usage but can be struggling due to processes waiting for time on the CPU.
  10. As an system integrator of Control4 I want to be sure that each system is not overloaded, monitoring systems gives you an idea on what controller the next customer should go for an why. We have a demo system running a EA1 with lots of drivers and lots of automation programming. And monitoring the SNMP Load Average shows a steady 6+. Sometimes peaking at 9+. And from my understanding the EA1 seems to have 4 cores?, meaning 6 or 9 in load is very bad. But then again the system seem fine. CPU seems fine and low, the memory on the other hand is low but steady on 21% left. Have anyone else done some research and monitoring on this?
  11. Probably need more work. But any idea on what can be wrong and what part that needs a better look?
  12. I have come across this weird issue that happens on initial boot up. The lights does not work. And the way to get them working again is even more weird. Where you have to go into composer, open the light which then is shown with grayed out fields. Then close the window, then open the light again now the light is showing functioning buttons. And starts working from app etc. There is also another weird problem with tracking. The light scene tracking does not work before you have again gone into the light and done a manual random "set value". If you activate a light scene it will not show as active before you have done this. Its only after this is done that tracking is working. All of this is needed to be done on all lights/dimmers before they work/track after a reboot. The drivers is v2 proxy, but they do control an external system lighting. Anyone with any idea on why this is? Especially input from people working with driver creation would be nice. This is how a dimmer looks like after opening the driver window. Closing and opening the same dimmer will now show values. But you need to do a random "set level" before tracking will start working.
  13. The problem seemed to lie with the VPN blocking something, not sure what as I haven't had time to dig into this. Using the integrated remote connection worked eventually. But it was really slow and one of the reasons I rather use our own VPN solution.
  14. I am wondering if there are any other knx motion sensor drivers available, than the one in the library? The one in library does not seem to show up as a motion sensor in the app. And the driver has a relay output that cannot be connected with a generic motion sensor driver, as those are contact. Anyone with a solution to this? I have been searching but not finding anything so far. It seems a bit strange that this isn't more common. EDIT: I did find this KNX Sensor driver with 1 group address, that has 1 contact output, which means it can be used for many things. So that can then be linked with a generic motion sensor driver. https://technet.genesis-technologies.ch/control4-drivers/knx/sensors-and-relays/
  15. VegardK

    Programming with Advanced Lighting Scenes

    In my case the problem is a bug with the HomeSeeer Dimmer driver. After a reboot I have to go into composer and manually set a random value to the tracking lights. once done the tracking works. Its weird, but we will find it out eventually.