Solace CLI is a powerful tool for getting state/status info on various parts of the appliance (fibre cable, network cable, power module, ADB, HBA, redundancy state, etc.) We have problems understanding some of the info shown in the CLI output. Does anyone know of any references/documentation on the CLI output?
Thank you.
The general answer is - http://docs.solace.com/.
I don't think there really is a directory or annex of sorts for documenting all aspects of CLI show commands. You would see the specific show commands and their output being described in deeper detail in the specific chapters where the individual topics are described and explained in greater detail. In a way, I feel that this is better for the reader to deep-dive into a topic. If you need to find something quick, the search bar is quite powerful to quickly get to the reference.
As for some of the topics you've mentioned in the question...
Redundancy for appliances:
https://docs.solace.com/Configuring-and-Managing/Monitoring-Appliance-Redundancy.htm
Redundancy for software brokers:
https://docs.solace.com/Configuring-and-Managing/SW-Broker-Specific-Config/Monitoring-SW-Broker-Redundancy.htm
All things on guaranteed messaging monitoring:
https://docs.solace.com/Configuring-and-Managing/Monitoring-Guaranteed-Messaging.htm
For some other topics, the output is sort of what you'd expect to see in a typical Linux system and is thus self-explanatory, e.g., show interface <name>:
https://docs.solace.com/Configuring-and-Managing/Monitoring-Physical-Interfaces-and-IP-VRFs.htm
show hardware details would be similar to that of a fully expanded Device Manager in Windows or lshw or lspci in Linux. Brief description is covered in: https://docs.solace.com/Configuring-and-Managing/Montoring-Blades.htm
Just use search and ideally it shouldn't take you more than a click or two to get to what you need.
Related
I bought a Zipato Bulb 2. The datasheet and user's manual are very minimalist with no comprehensive description of the available commands. I looked into the XML description of OpenZWave but it is also incomplete.
So I asked Zipato directly, but the contact I made is not on the technical side and he doesn't know what I am talking about.
How am I supposed to interact with Z-Wave products if I don't know the command they provide?
I'm not sure if you've seen this information, but here's a link to the user manual for the Zipato Bulb 2. It covers the command classes that the bulb uses. It should be the same as the OpenZWave XML file.
The devices don't usually come with much more documentation than that. Is there something you still don't understand after having read it?
You can find the list of command classes in the ZWave Alliance product database
https://products.z-wavealliance.org/products/2712/classes
Openzwave didn't support currently the Command Class Firmware Update Md V2, otherwise, all others CC reported are supported.
I have not found the manufacturers of devices to be a useful source of info. Best thing to do is to ping your controller through its API. The command will vary with difference controllers, but with an ISY994i controller, as an example, I would use the following command:
192.168.X.YYY/rest/nodes
X.YYY is the local address of your controller on the network.
With my controller, this lists all devices and their sub-devices. For example:
AEON LABS SMART ENERGY SWITCH (DSC06106-ZWUS)
<node flag="128" nodeDefId="UZW0019">
<address>ZW004_1</address>
<name>ZW Main Computer</name>
<pnode>ZW004_1</pnode>
<cat>121</cat>
<property id="ST" value="0" formatted="Off" uom="78"/>
<node flag="0" nodeDefId="UZW002B">
<address>ZW004_143</address>
<name>ZW Main Computer Meter</name>
<pnode>ZW004_1</pnode>
<cat>143</cat>
<property id="ST" value="104991" formatted="104.991 Watts" uom="73" prec="3"/>
Again, it's going to be completely different for your controller, but you get the idea. Look to the controller's API, not the device manufacturer, for details on what variables you can set in Z-wave devices. Also, some controllers will support functions that other controllers don't support. Which z-wave chip is in the controller vs the device will also change what you see through the controller API.
I need to implement a software module that is able to retrieve the topology of an autonomous system.
Looking at the various protocol that are implemented in Cisco routers i concluded that the only two alternatives to obtain topology are smnp and ospf.
The first one is a workaround and i don't want to use it, this leads to ospf.
I haven't found library in c, java and python that are usable; this one ( http://www.ospf.org/ )is probably the most complete but comes without documentation and i don't have enough time to analyze all the code.
So i found quagga that can implement a software ospf router; seems the perfect alternative since it can work with both real network and simulated network in gns3.
But it's possible to obtain the ospf routing table from quagga since everything is from command line?
This are my conclusions and doubts if someone can suggest something better or help me with the next step it would be appreciated since i'm stuck at the moment.
Use quagga's ospfclient feature. There is already an example provided in the ospfclient directory (see ospfclient.c) which will show you how to retrieve the LSA database from a quagga/ospfd instance. For this solution to work you need to attach a PC to one of your OSPF backbone routers and configure quagga/ospfd on it to successfully learn the routes then you start your ospfclient to retrieve any information you need.
I have question to ask you.
There are some open source robotic middleware out there that contains some libraries for robotic developers to do I/O works. They are really powerfull tools that save a lot of time.
They are such as OpenRTM, OROCOS, RSCA etc...
In a project, we will developing a robotic wheelchair that do some autonomous behaviors such as obstacle avoidance, move2goal, follow coridor etc. We'll use an RTOS to organize I/O stuff and selection operations for the behaviors.
What I'm wondering is if any of the RTOS(mcOS-II, QNX, Keil etc.) has port to these middlewares? Can I install them on to these RTOSes?
Sorry for my bad English. Hope you got what I mean.
My best regards..
I am OpenRTM-aist user.
OpenRTM-aist have QNX implementation.
http://www.openrtm.org/openrtm/ja/node/5056
Sorry, there is no english documentation for OpenRTM for QNX, please use google translate button on the site.
OpenRTM-aist is also available for Real-Time Linux (ART-Linux, real-time preemption kernel), T-Kernel (uITRON), VxWorks (developed by SEC CO. LTD.).
Sorry, they do not have english pages, but developers are of course available for english communication. Ask them in the mailiing list: I also recommend you to use openrtm-user mailing list. We had a similar question a couple days ago. You must be able to get some useful information on it.
You can find link on the official OpenRTM-aist website, described above.
Of course, english is welcome!
Is it possible to get location data out of Google Gears, Google Gelocation API or any other web location API (such as Fire Eagle) in such a format that it appears to other software as a GPS device?
It occured to me reading these answers to my question regarding WiFi location finding, on Super User, that if I could emulate a GPS unit, many of these web services could act as a 'poor-mans' GPS to otherwise less useful software that requires it.
Is GPSD an option?
Preferably OSX & Python, but I would be interested in any implementation.
There is a very similar thread on a Python mailinglist that mentions Windows virtual COM ports and discusses Unix's pseudo-tty capabilities. If the app(s) you want to use let you type in a specific tty device file, this may be the easiest route. (Short of asking the authors to provide a plugin API for what you're trying to do, or buying yourself a $20 bluetooth GPS mouse.)
Are you using OS X?
There is a project macosxvirtualserialport on Google code that provides a graphical wrapper around some of the features of a utility called socat. I'd recommend taking a look at socat if you see potential in the pseudo-tty route. I believe you could use socat to link a pipe from a Python program to a pseudo-tty.
Most native Mac apps will be querying IOServiceMatching for a device with kIOSerialBSDRS232Type, and I doubt that a pseudo-tty will show up as an IOKit service.
In this case, unless you can find a project that has already implemented such a thing, you will need to implement a driver as described in this How to create virtual COM port thread. If you're going to the trouble of create a device driver, you would want to base it on IOKit because of that likely IOServiceMatching query. You can find the Apple16X50Serial project mentioned in that post at the top of Apple's open source code list (go to the main page and pick an older OS release if you want to target something pre-10.6).
If your app is most useful with realtime data (e.g. the RouteBuddy app mentioned in the Python mailinglist thread can log current positions) then you will want to fetch updates from your web sources (hopefully they support long-polling) and convert them to basic NMEA RMC sentences. You do not want to do this from inside your driver code. Instead, divide your work up into kernel-land and user-land pieces that can communicate, and put as little of the code as possible into the kernel part.
If you want to let apps both read and write to these web services, your best bet would probably be to simulate a Garmin device. Garmin has more-or-less documented their protocol in the IntfSpec.pdf file included with their Device Interface SDK. Again, you'd want to split as much as you could into user-space code.
I was unable to find a project or utility that implements the kernel side of an IOKit-based virtual serial interface, but I'd be surprised if there wasn't one hiding somewhere out there. Unfortunately, most of the answers I found to that question were like this, with the developer being told to get busy writing a kext.
I'm not exactly sure how to accomplish what you're asking, but I may be able to lend some insight as to how you might begin to get it done. So here goes:
A GPS device shows up to most systems as nothing more than a serial device -- a.k.a. a COM port if you're dealing with Windows, /dev/ttySx if you're in *nix. By definition, a serial port's specific duty is to stream data across a bus, one block at a time. So, it would then follow logically that if you want to emulate the presence of a GPS device, you should gather the data you're consuming and put it into a stream that somehow acts like an active serial port.
There are, however, some complications you might want to consider:
Most GPS devices don't just send out location data; there's also information on satellite locations, fix quality, bearing, and so on. Then again, nobody's made any rules saying you have to make all that data available. There's probably more to this, but I'll admit that I need to do more research in this area myself.
I'm not sure how fast you can receive data when dealing with Google Latitude, etc., but any delays in receiving would definitely result in visible pauses in your "serial port"'s data stream. Again, this may not be as big a complication as it seems, because GPS devices are known to "burst" data across the bus anyway, but I'd definitely keep an eye on that. You want to make sure there's always a surplus of data coming across, not a shortage.
Along the way you'll also have to transform the coordinates you receive into valid GPS sentences, as well. You can find specifications for those, but I would definitely make friends with the NMEA standard -- even though it is a flawed standard, it's the one everyone seems to agree on anyway.
Hope this helped you, at least a little bit. Are there anymore details specific to your problem that you think could be useful in answering this question?
Take a look to Franson GPS Gate which allows you to connect to Google Earth among other things (like simulating GPS and so on). Is windows only though but I think you could get some useful ideas from it.
I haven't looked into it very much, but have you considered using Skyhook's SDK? It might provide you with some of what you are looking for. It's available for every major desktop and mobile OS.
I have been working with Carmen http://carmen.sourceforge.net/ for a while now, and I really like the software but I need to make some changes inside the source code.
I am therefore interesting in some students reports/projects there have been working with Carmen, or any documentation of the source code.
I have been reading the documentation on the webpage for Carmen, but with all respect I think the literature there is a bit outdated and insufficient.
ROS is the new hot navigation toolkit for robotics. It has a professional development group and a very active community. The documentation is okay, but it's the best I've seen for robotic operating systems.
There are a lot of student project teams that are using it.
Check it out at www.ros.org
I'll be more specific on why ROS is awesome...
Built in visualizer/simulator rviz
- It has a record function which will record all of the messages passed out of nodes, this allows you take in a lot of raw data store it in a "ros bag" and then play it back later when you need to test your AI, but want to sit in your bed.
Built in navigation capabilities,
-all you have to do is write the publishers of data for your sensors.
-It has standard messages that you need to fill out so that the stack has enough information.
There is an Extended Kalman Filter which is pretty awesome because I didn't want to write one. Currently implementing it, i'll let you know how that turns out.
It also has built in message levels, by that I mean you can change which severity of print messages are printed during runtime, fairly handy for debugging.
There's a robot monitor node that you can publish the status of your sensors to and it bundles all of that information into a GUI for your viewing pleasure.
There are some basic drivers already written. For example SICK lidars are supported right out of the box.
There is also a built in transform function, to help you move everything to the right coordinate system.
ROS was made to run across multiple computers, but can work on just one.
Data transfer is handled over TCP ports.
I hope that's more helpful.