@aimc if i have read it correctly is bash not easy available, just like a normal program.
if i could just download, install and work with it, i would consider it.
allthough that i am not really a Linux fan. if i could easyly install a microsoft enviroment on my PI i would also do that
i have almost 25 years of experience in microsoft enviroment and fast zero in Linux, and with all the new things im learning that makes it easier
i think that for future users (and me) it would be nice if you would make an check in the pycode.
check at start if it is a Linux or microsoft enviroment, and if it is microsoft then blend out the part that dont work.
i have no idea what those part do, but that is something you could document to give a choice for bash.
it would bring something for you to. right now im satisfied as it is and i dont update because off the extra things to do.
that makes that im not a tester from your latest version anymore. if you make app so that i wont have to do things after update i will be testing your latest version as soon as it is there
It’s very easy to install the Bash shell, and it seems to be 100% compatible with other Linuxes, however, it shouldn’t be too hard to come up with a windows version - you only lose 2 things:
The ability to use signals to dump diagnostic information
The ability to run as a Daemon
Neither are essential. I’ll take a look at a new version at the weekend.
in python i can use lots off ways to retrieve diagnostics info, so i dont think i will miss that.
and i’m ashamed to say but i have absolutily no idea what a deamon is in this case.
so maybe i would like that in the future, but i cant miss what i dont know
@ReneTode in Windows-land terms, a daemon is essentially a service. It’s a program that runs in the background while you do other things. Usually without having a control window or interface. You set it to run (manually or at startup), it executes, and does what it does. My guess is you are already familiar with programs like these, and it is just the term that is unfamiliar.
And I would add that when running a service in windows you won’t need the -d flag in all likelihood so no loss there.
The diagnostics from the signals are internal information about the scheduler and callbacks that could be useful to me in some situations but again, not essential - I’ll see if I can come up with another way to gather it if needed.
One question @ReneTode - what python are you using for WIndows so I can test in an identical environment?
@Zen thx. i couldnt let it go this afternoon, so a started searching, and found those things out.
i already started to try some options to deamonize in windows enviroment.
probably that needs a third party program, but it should be quite simple.
i must say i dont see a lot off advantage from it, i dont like things to run, when i dont see it. if it would make it a lot faster, but even that advantage is not really there.
but ill search for a easy deamonize windows option. @aimc if im not mistaken i have chosen 3.4
3.5 had some disadvantages mentioned when i started with python, and i hadnt started anything before so i didnt see the advantage from 2.7 at that time (although i am not a fan from installing anything then the latest version)
but you dont have to make a testenviroment especially for me andrew. i have no problem running into something once in a while, if i know that that can happen. i even would like to test things before you release them, because i like the way you think.
"Before running AppDaemon you will need to install the package:
$ sudo pip3 install . "
What package I need to install?
When I run this command:
$ appdaemon -c conf/appdaemon.cfg
get this error: appdaemon: command not found.
Please give me some advise.
The command “sudo pip3 install .” Is the command that installs the AppDaemon package. After you run that command appdaemon is installed and you can run it with the command you were using.
From the terminal, change into the appdaemon directory that you cloned the git repository to, and once you are in there, simply type that command:
sudo pip3 install .
Don’t forget the space and period at the end. What the line is doing is telling the python installer “pip3” to install the python application that is in the current directory. The period means “here” as in “this directory”
This command will install appdaemon into /usr/local/bin/ which is a path in your environment variables so that when you type appdaemon anywhere on the system it will look inside the known paths and find the application without you having to type /usr/local/bin/appdaemon
Obviously it does more than just create the application in that path, but for your purposes, thats all you need to know to get this to work.
The directory ‘/home/trungbn/.cache/pip/http’ or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo’s -H flag.
The directory ‘/home/trungbn/.cache/pip’ or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo’s -H flag.
Processing /home/trungbn/appdaemon
Requirement already satisfied (use --upgrade to upgrade): appdaemon==1.2.0 from file:///home/trungbn/appdaemon in /usr/local/lib/python3.4/dist-packages
Requirement already satisfied (use --upgrade to upgrade): daemonize in /usr/local/lib/python3.4/dist-packages (from appdaemon==1.2.0)
Requirement already satisfied (use --upgrade to upgrade): sseclient in /usr/local/lib/python3.4/dist-packages (from appdaemon==1.2.0)
Requirement already satisfied (use --upgrade to upgrade): configparser in /usr/local/lib/python3.4/dist-packages (from appdaemon==1.2.0)
Requirement already satisfied (use --upgrade to upgrade): astral in /usr/local/lib/python3.4/dist-packages (from appdaemon==1.2.0)
Requirement already satisfied (use --upgrade to upgrade): requests>=2.6.0 in /usr/local/lib/python3.4/dist-packages (from appdaemon==1.2.0)
Requirement already satisfied (use --upgrade to upgrade): six in /usr/lib/python3/dist-packages (from sseclient->appdaemon==1.2.0)
Requirement already satisfied (use --upgrade to upgrade): pytz in /usr/local/lib/python3.4/dist-packages (from astral->appdaemon==1.2.0)
but when I run command:
trungbn@TrungPC:~/appdaemon$ sudo appdaemon -c conf/appdaemon.cfg
[sudo] password for trungbn:
input the pass then nothing happen. No information display. I already successful in running appdaemon v1.0.
One of the things I miss most after converting to HA is the ability to trigger events randomly +/- a set amount of time around sunrise or sunset. I have imported random and can make the app trigger a set amount of time after sunrise or sunset but cannot for the life of me figure out how to make it trigger before. I suppose that if I wanted +/- 30 minutes I could set it to -60 minutes in the init section of the class and then set a random number between 1 and 60 in the callback. Just not sure this is the wisest way to accomplish this. Any suggestions?
A negative number will trigger before sunrise or sunset, so just generate a random number from 1 to 60 then subtract 30 for example to get plus or minus 30 seconds (obviously multiply by 60 to get minutes) - will that do what you need?
Edit: to get it to fire at a different time each day I would set a callback to run at say 60 mins before sunset, then use run_in() with a random number of seconds (e.g. 0 - 120*60) to call a second callback that actually turns the light on or whatever.
I might look into adding randomized times to some of the scheduler calls. I think that would be useful.
Yes but will generating a random number and replacing the -30 with that number in the below statement from the init section of the class generate a different number on a daily basis?
Just started using this yesterday…all I can say is… WOW and Thank You.
This is saving me so much time & frustration. I can finally do all the things I had to settle with because the limitations of the YAML based automatons.
I did notice that the example for get_app() in the API.doc is for split_entity() so you may want to fix that.
Also any chance for using multiple Callback Constraints of the same type in the config?
I would love to be able to use multiple input_boolean or input_select Callback Constraints.
Huge Props to all the Home-Assistant Devs & Community for all their hard work & making Home Automation fun & enjoyable. This is a fantastic community.
